我有一堆文件。现在只有大约100,000。但是我可能有数百万。这些文件每个大约15KB。
现在，我计算分区键的方法是从Sql中获取ID字段，该字段设置为自动递增1，然后将该数字除以1000。我认为这不是一个好主意。
有时，我必须通过并行写入来非常努力地访问CosmosDB。当我这样做时，文档通常具有非常紧密分组的SQL ID。例如，像这样：
12000
12004
12009
12045
12080
12090
12102
如您所见，所有这些文档都将同时写入同一个分区，因为它们的分区键均为12。从我阅读的文档来看，这是不好的。我应该在分区之间散布我的作品。
我正在考虑更改此设置，以便PartitionKey是Sql Id除以10,000加最后一位数字。假设同时写入的一组Id是随机分布的（它们几乎是这样）。
像这样：
(12045 / 10000).ToString() + (12045 % 10).ToString()
这意味着，鉴于上面的列表，分区键将为：
12000: 10
12004: 14
12009: 19
12045: 15
12080: 10
12090: 10
12102: 12
不是将所有7个写入单个分区，而是将所有7个写入10、12、14、15和19分区（共5个）。这会导致更快的写入时间吗？对阅读时间有什么影响？我这样做正确吗？
还有，让密钥的第一部分是Id / 1000还是Id / 1000000更好吗？换句话说，拥有许多小分区会更好吗？还是我应该努力填补单个分区的10 GB限制？
答案 0 :(得分：0)
您应该致力于在分区之间平均分配负载。 10gb是限制，您不应以达到该限制为目标（因为那将意味着您将无法再将文档添加到分区）。
创建合成分区键是在分区之间平均分配文档的有效方法。找到\发明适合您的加载方式的密钥由您决定。
答案 1 :(得分：0)
您可以简单地获取ID的最后一位，从而很好地将文档分散在10个分区上。
关于您对最大分区的评论：hashKey的值被散列，而该散列确定物理分区。因此，当partitionKey具有1.000个可能的值时，并不意味着您具有1.000个分区。