在 Azure Cosmos DB 中选择 PartitionKey
Choosing A PartitionKey in Azure Cosmos DB
我有一堆文件。现在只有大约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 更好？换句话说，是小分区多一些好还是我应该以填满单个分区的10GB限制为目标？
您的目标应该是在分区之间平均分配负载。 10gb 是限制，您不应以达到该限制为目标（因为那意味着您将无法再向该分区添加文档）。
创建合成分区键是在分区之间均匀分布文档的有效方法。 find\invent 适合您的负载模式的密钥取决于您。
您可以简单地使用您的 ID 的最后一位数字，这样就可以很好地将文档分布在正好 10 个分区上。
关于您对最大分区的评论：partitionKey 的值经过哈希处理，该哈希决定了物理分区。因此，当您的 partitionKey 有 1.000 个可能值时，并不意味着您有 1.000 个分区。
我有一堆文件。现在只有大约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 更好？换句话说，是小分区多一些好还是我应该以填满单个分区的10GB限制为目标？
您的目标应该是在分区之间平均分配负载。 10gb 是限制，您不应以达到该限制为目标（因为那意味着您将无法再向该分区添加文档）。
创建合成分区键是在分区之间均匀分布文档的有效方法。 find\invent 适合您的负载模式的密钥取决于您。
您可以简单地使用您的 ID 的最后一位数字，这样就可以很好地将文档分布在正好 10 个分区上。
关于您对最大分区的评论：partitionKey 的值经过哈希处理，该哈希决定了物理分区。因此，当您的 partitionKey 有 1.000 个可能值时，并不意味着您有 1.000 个分区。