我们有一个多租户应用程序，它使用Azure DocumentDB作为面向NoSQL文档的数据库。
对于多租户，我们阅读了这个问题和这篇博客文章。因为目前我们的用户数量无法满足使用不同数据库和/或documentCollections的需求，更重要的是，为了节省成本，我们在一个带有documentCollection的TenantId字段上使用了"Where"子句来实现多租户。
同样，当涉及到存储具有完全不同性质的"文档"或"对象"（例如Book和Car）时，我们在质疑使用一个documentCollection的事实。
首先，为Book和Car创建两个不同的documentCollection看起来更合理。但是，创建documentCollection的成本最低为25美元。我们不想每次需要添加新功能时都支付+25美元，即使是存储少量数据（例如，我们的应用程序存储了大量Books，但很少存储Cars…）。
将Book和Car放在同一个documentCollection中是一个好的设计吗？并在共享成员（例如string Type ="Book" or string Type = "Car"）中保留对文档类型的引用。
我们知道我们已经实现了带有Where"子句"的多租赁，为了查询应用程序中给定租户的所有汽车，我们的查询都将包含Where TenantId ="XXXX" AND Type = "Car"。
我已经看到DocumentDB现在支持分区集合。这是对分区的良好使用吗？相反，应该保留分区以实现更好的可扩展性，并且不适合隔离对象数量可能不相似的不同文档类型？
是的，使用type="Book"是"好的设计"。您还可以执行isBook=true，我认为它的效率稍高，可以实现继承和混合行为。
分区集合实际上是一种将更多内容放入单个更大实体中的方式，而不是相反。其想法是允许吞吐量（RU）和空间的扩展，而无需自己管理多个集合。你"可以"让你的分区键成为你的type字段，但我不建议这样做。分区键应该能够在分区之间大致均匀地分布。。。以及其他标准。