azure-cosmosdb - CosmosDB/DocumentDB 在同一集合中使用多种类型进行分区

Question

据我所知，团队的官方建议是将所有数据类型放入单个集合中，例如 type=someType文档上的字段以区分类型。

现在，如果我们假设具有分区的大型数据库，其中不同的对象类型可以是:

完全不同的字段(因此没有用于分区的通用字段)

相关(通过引用)

如何组织事物，以便应该在一起的事物最终在同一个分区中？

例如，假设我们有:

用户

博客帖子

博文评论

如果我们使用 type=user|blogPost|blogPostComment 将它们存储为单独的类型, 在同一个集合中，我们如何确保用户、他的博文和所有相应的评论最终在同一个分区中？
是否有一些最佳实践？

[更新]
你能完全避免跨分区查询吗？这应该是一个目标吗？或者您只是尝试将它们最小化？
例如，您可以为 99% 的案例/查询完美地分区数据，但随后您需要一些仪表板来显示所有数据的聚合。这是你认为不可避免的事情并试图最小化还是有可能完全避免它？

Answer 1

I've written about this somewhat extensively in other similar questions regarding Cosmos.

基本上，在单个 Cosmos 集合中处理许多不同的逻辑实体类型时，最简单的选择是在所有文档上放置一个通用(或抽象，如您所指)分区键。在这一点上，确保在运行时选择适当的值是应用程序的关注点。我通常将此文档属性命名为 partitionKey , routingKey或类似的东西。

这在设计最佳查询效率时非常重要，因为您选择的分区键会对查询和吞吐量性能产生巨大影响。像这样的通用 key 可让您设计数据的最佳存储，因为它有益于您正在构建的任何应用程序。

甚至像 tenant没有意义，因为不同的租户可能具有截然不同的数据大小和访问模式。相反，您可以包含 tenantId在运行时作为分区键的一部分作为一种组合。

更新:
对于某些查询模式，可能可以完全在单个分区之外为它们提供服务。如果事情最终发生交叉分区，这绝对不是世界末日。系统还是很快的。如果可能，限制给定查询需要触及的分区数量是理想的，但您永远不会 100% 的时间摆脱它。