我们有一个多租户应用程序，它使用Azure DocumentDB作为我们的NoSQL面向文档的数据库。
对于多租户，我们会先阅读this question和this blog post。因为现在我们的用户数量不满足使用不同数据库和/或documentCollections的需要，更重要的是，为了节省成本，我们在TenantId字段上使用“Where”子句实现多租户，其中一个{{1 }}
同样地，当涉及存储具有完全不同性质的“文档”或“对象”时（例如documentCollection和Book），我们对使用一个{{1 }}。
首先，为Car和documentCollection创建两个不同的documentCollection似乎更合理。但是，创建Book最低费用为25美元。每当我们需要添加新功能时，即使要存储少量数据，我们也不想支付+ 25美元（例如，我们的应用程序存储了大量Car但很少documentCollection。 ）。
将Book和Car放在同一个Books中是一个好的设计吗？并在共享成员中保留对文档类型的引用（例如Cars）。
知道我们已经使用Where“子句”实现了多租户，要查询我们应用中针对给定租户的所有汽车，我们的查询都将包含documentCollection。
我已经看到DocumentDB现在支持Partitioned Collection。这可能是分区的良好用法，或者相反，它们应该保持以实现更好的可扩展性，并且不适合分离对象数量可能不相似的不同文档类型？
答案 0 :(得分：12)
是的，使用type="Book"是“好的设计”。您也可以执行isBook=true，我相信它会稍微提高效率并启用继承和mixin行为。
分区集合实际上是一种将更多东西放入一个更大的实体而不是相反的方式。我们的想法是允许扩展吞吐量（RU）和空间，而无需自己管理多个集合。您“可以”将您的分区键设为type字段，但我不建议使用它。分区键应该能够在分区之间大致均匀分布......以及其他标准。