2016-04-20 17 views
7

Chúng tôi có một ứng dụng multitenant sử dụng Azure DocumentDB làm cơ sở dữ liệu định hướng tài liệu NoSQL của chúng tôi.Lưu trữ các loại tài liệu khác nhau trong một bộ sưu tập DocumentDb

Đối với đa nhiệm, chúng tôi đọc this questionthis blog post. Bởi vì hiện tại số lượng người dùng của chúng tôi không đáp ứng nhu cầu sử dụng các cơ sở dữ liệu khác nhau và/hoặc documentCollections, và quan trọng hơn, để tiết kiệm chi phí, chúng tôi đã triển khai đa nhiệm với mệnh đề "Where" trên trường TenantId với một documentCollection.

Tương tự, khi lưu trữ "tài liệu" hoặc "đối tượng" với các bản chất hoàn toàn khác nhau (ví dụ: BookCar), chúng tôi đang tự hỏi mình về thực tế sử dụng một số documentCollection.

Lúc đầu, có vẻ hợp lý hơn để tạo hai khác nhau documentCollection cho BookCar. Tuy nhiên, việc tạo chi phí documentCollection tối thiểu là 25 đô la. Chúng tôi không muốn trả + 25 đô la mỗi lần chúng tôi cần thêm tính năng mới ngay cả khi nó lưu trữ một lượng dữ liệu thấp (ví dụ: ứng dụng của chúng tôi lưu trữ rất nhiều Books nhưng ít Cars ...).

Đây có phải là thiết kế tốt để đặt Sách và Xe hơi trong cùng một documentCollection không? Và giữ tham chiếu đến loại tài liệu trong một thành viên được chia sẻ (ví dụ: string Type ="Book" or string Type = "Car").

Biết rằng chúng tôi đã triển khai Multitenancy với mệnh đề "Where", để truy vấn tất cả Ô tô trong ứng dụng của chúng tôi cho một đối tượng thuê nhất định, các truy vấn của chúng tôi sẽ chứa Where TenantId ="XXXX" AND Type = "Car".

Tôi đã thấy rằng DocumentDB hỗ trợ ngay bây giờ là Partitioned Collection. Điều này có thể là cách sử dụng tốt các phân vùng hay ngược lại, chúng phải được giữ để đạt được khả năng mở rộng tốt hơn và không thích nghi để tách biệt các loại tài liệu khác nhau mà số lượng đối tượng có thể không giống nhau?

Trả lời

8

Vâng, đó là "thiết kế tốt" để sử dụng type="Book". Bạn cũng có thể làm isBook=true, điều tôi tin là hiệu quả hơn một chút và cho phép hành vi thừa kế và mixin.

Bộ sưu tập được phân vùng thực sự là một cách để đưa nhiều nội dung vào một thực thể lớn hơn thay vì theo cách khác. Ý tưởng là cho phép mở rộng quy mô của cả thông lượng (RUs) và không gian mà không có gánh nặng quản lý nhiều Bộ sưu tập. Bạn "có thể" làm cho khóa phân vùng của bạn là trường type của bạn, nhưng tôi không khuyên bạn nên sử dụng nó. Các phím phân vùng nên cho phép phân bố thậm chí khoảng cách giữa các phân vùng ... trong số các tiêu chí khác.

+0

Cảm ơn bạn đã trả lời nhanh chóng. Chỉ cần chắc chắn rằng khi bạn viết "Các phím phân vùng sẽ cho phép phân bố thậm chí khoảng cách giữa các phân vùng ... trong số các tiêu chí khác." Bạn có nghĩa là các phím phân vùng được sử dụng để tạo ra "phân vùng có kích thước tương tự"? –

+0

Chúng tôi cũng đang điều tra thư viện [lumenize] (https://github.com/lmaccherone/documentdb-lumenize) của bạn để cho phép các hàm tổng hợp thành DocumentDb. Trông rất hứa hẹn. –

+0

Kích thước và thông lượng tương tự. Hãy cho tôi biết nếu bạn cần trợ giúp với Lumenize. Tôi theo dõi thẻ Stack Overflow cũng như thẻ này. –

Các vấn đề liên quan