唯一 ID 是 CosmosDB 的最佳分区键吗答案

【问题标题】：Is a unique ID the best partition key for CosmosDB唯一 ID 是 CosmosDB 的最佳分区键吗
【发布时间】：2020-08-02 10:44:52
【问题描述】：

我正在尝试为 CosmosDB 表确定最佳分区键，该表同时具有客户 ID（每个客户的唯一值）和客户城市（在北美，这会产生数千个可能的值）。

阅读 Azure 文档后，我看到了很多相互矛盾的信息，其中一个是最好的。一些文档指定越独特的值将提供更好的跨分区项目分布。而其他文件则表明最好使用城市。

所以我的问题是：

每个分区键是否都经过哈希处理，每个分区是否包含具有一系列哈希键的项目？即 - 如果客户 ID 是分区键，一个分区的 ID 是否为 1 到 1000，另一个分区的 ID 为 1000 到 2000，等等？城市也是一样，一个分区会有多个城市吗？或者，每个分区是否会 1:1 映射到特定的分区键 - 即 ID 或城市？
基于上述，哪一个会更好（性能更高，成本更低）？拥有尽可能精细的分区键（id 客户 ID）？还是客户城市？

谢谢！

【问题讨论】：

没有人能告诉您什么最适合您的特定应用。每条记录都有一个分区不会给您带来任何好处，如果您必须进行跨分区查询，可能会导致问题

标签： azure-cosmosdb

【解决方案1】：

是的，分区键是散列的，这些散列确定逻辑分区的物理存储位置
不，分区只会包含具有相同分区键的记录（这基本上就是重点，将关联的记录放在一起）。因此，在您的示例中，它们将按 1:1 映射
成本无关紧要，因为您无需为分区付费（尽管它们确实有大小限制），所以问题归结为性能，这完全取决于您的应用程序如何查询数据。

理解分区如何工作的一个很好的类比是考虑查找某人的地址：

如果我给了你我房子的钥匙（物品 ID），但没有别的，你需要尝试世界上的每一扇门，直到你碰巧找到正确的门（也就是跨分区查询）。如果我告诉您国家（分区键），那么您可以立即消除数百万扇门，但您仍然需要检查数百万扇门，因此效率仍然不高。如果我给你城市，那么再少一点，但还有很多要检查的地方....但是如果我给你我的邮政编码，那么我们刚刚将查询从数十亿条记录优化到 15-20 条。

【讨论】：

可能是个坏例子，你怎么知道不同国家的邮政编码不冲突？
@4c74356b41 为什么这使它成为一个坏例子？重点仍然存在，即使它们在全球范围内发生冲突的可能性很小，您也需要搜索一个非常小的数据集。 PK 不应该是唯一的……
哈希国家+邮政编码将是一个更好的选择。再说一次，我不确定人们在邮政编码中的分布有多均匀（我的猜测：根本没有），所以使用邮政编码可能是一个天生不好的 PK 导致热分区
@4c74356b41 抱歉，但我不同意，您完全过度分析了一个简单的类比，并且基于总的猜测工作 - 请启发我，各国重复邮政编码的比例是多少？另外，鉴于这不是一个字面示例，并且我在英国使用了一个快速统计数据，即邮政编码下大约 15-20 个地址，您能否详细说明为什么您认为该线索会导致热分区？
为什么这个比例很重要，如果存在一个骗子 zip + country 将是一个更好的 PK。邮政编码只是位置的代理。按位置对人进行分组总是会导致热分区，因为（你猜怎么着），大多数人倾向于住在大城市，所以人们已经按位置分组，你只是在你的数据库设计中复制它。这不聪明。