Azure Cosmos DB 分区键 - 主键是否可以接受？

Question

我们的 Azure Cosmos DB 集合已经足够大，需要一个分区键。 在阅读有关此内容时，我的印象是最好的分区键是提供均匀分布和更高基数的键。 Microsoft 的这篇文章对此进行了讨论。

使用主键作为分区键提供了均匀分布，但基数仅为 1。如果这是我唯一的选择，这是一件坏事吗？ 前面提到的文章给出了几个例子，似乎表明在这些情况下应该将主键用作分区键。 对于 Azure Cosmos DB，分区是逻辑的，而不是物理的。 所以它不会导致每个文档都在自己的磁盘上，但它似乎可能导致索引膨胀。

使用主键作为分区键是一种常见做法吗？ 它有什么缺点吗？

Answer 1

其实，分区键的选择是一个值得反复权衡的问题。 由于选择主键作为分区键是您唯一的选择，我只讨论一些可能的负面事情作为您的参考。

在性能方面，如果你查询的字段不是partition key，你的查询肯定会因为跨分区而降低查询性能。 可以说，如果数据量很小，它不会有太大的影响。

成本方面，cosmos db主要是按存储空间和RUs消耗来收费的。如你所说，选择主键作为分区键会导致更多的索引存储。 如果大多数查询是跨分区的，也会导致更多的 RU 消耗。

在使用存储过程、触发器或UDF方面，不能通过存储过程和触发器使用跨分区事务。 因为 then 是分区的，所以在使用它们时需要指定分区键（基数仅为 1）。

请注意，如果创建了分区键，则以后无法删除或修改它。 因此，在选择之前请考虑一下并确保进行数据备份。

更多细节，还是参考官方文档。

Answer 2

不，它没有缺点。 争取拥有高基数的分区键。 不要担心索引或物理分区等。

您可以拥有数百万个分区键和 10 个物理分区。 物理分区由 CosmosDB 在后台创建。 您永远不应该担心物理分区。

Answer 3

您可以说主键是分区键最安全、可能也是最合适的选择。

它保证值的唯一性，这是实现唯一键以外的唯一方法。 分布将是均匀的，因为主键将是您的分区键，您将能够使用它来通过读取而不是查询来检索文档，从而降低了操作速度和成本。

Answer 4

我认为 MS 在描述如何最好地确定 Cosmos DB 的分区键方面做得并不好 - 特别是如果人们通常建议使用数据库的主键作为分区键（有时这可能是完全可以接受的，但是我看不出这是正常的）。

在最近的一个项目中，这就是我们决定为系统中的对象识别分区键和项目 ID 的方式。 我认为这适用于许多在其对象上具有自然复合主键候选的系统。

在我们的系统中，每个对象都限于一个状态 (StateCode) 和供应商 (VendorId)。 从那里，我们有多个实体，如销售订单、客户、小部件……在我们的 SQL Server 实现中，每个表都有一个明显的自然复合主键 StateCode、VendorId、EntityId。 在 Cosmos DB 场景中，我们选择 Partition Key 为 StateCode-Vendor-EntityType，Item Id 为 EntityId。 这允许在分区内查询特定类型的所有实体（节省 RU），同时仍然允许在该分区内进行非常简单的查询（例如，同类实体）。 您最终以这种方式使用了复合自然键的所有部分，但允许对实体进行实际分区。

在更复杂的场景中，我们想要跨实体查询给定供应商，我们可以从分区键中删除 EntityType 并将其移动到项目 id 中或使用它来过滤正在搜索的对象。 这允许在分区内进行跨实体查询，但由于异构实体，查询本身稍微复杂一些。

如果实体的整个 ID 都在分区键中，那么您几乎必须始终单独查找项目或在不按 ID 查找时搜索每个分区 - 在这一点上，谁会关心您的数据在分区之间的分布是否均匀，如果无论如何你都必须搜索它们。

也许 OP 可以更多地描述实体——它们是否有自然的复合键候选（无论它们是否在 SQL 实现中使用）？ 如果不是，那么当前的持久层在通过某些 id 识别系统中的项目方面是什么样子的？