Azure cosmosdb Guid子串碰撞概率？

如何计算两个guid以相同N个字符开始的概率

情况：

我们正在考虑使用guid中的前n个字符作为cosmosdb集合分区键。我们不希望使用整个guid，因为我们不希望每个文档都位于其自己的逻辑分区中，但我们也可能不希望仅使用guid的第一个字符作为分区键，因为我们可能会在分区中存储太多文档，并溢出分区限制

示例：

因此，如果我们使用guid的前4个字符（随机抽取的数字）作为分区键，我们如何粗略计算每个分区每月将存储多少文档？在本例中，假设我们讨论的是每月对400万个文档进行分区

更新

---

听起来每个guid字符都有16个潜在值。0-9和a-f（十六进制字符集）。假设Guid字符是随机的（我不确定这是真的），应该有16^4个可能的四字符Guid开始（~65k个组合）。因此，我们最多有65k个分区。如果我们假设将4000000个文档随机分布到65000个分区中，那么每个分区大约应该有61个文档，对吗？

实际上，您可以得到集合分区的使用情况，通过它可以显示数据分布的情况

---

cosmos db中没有内置的预览功能，在存储数据之前显示分区使用情况。如果在使用之前确实关心分区使用情况，则可以先自己计算。例如，使用

groupby

按guid的前4个字符对数据进行分区。

在分区之间均匀分布数据只是等式的一半。你还需要考虑你将如何访问数据。如果您使用随机值进行分区，并且经常运行返回多个文档的查询，这将严重影响性能，因为您将执行大量跨分区查询。@Paul我理解并认为我们会很好。我们所做的是将索引存储到collectionA中的collectionB中。CollectionA是我在问题中所指的。我们将始终能够将shardkey传递到find谓词到collectionA中，因为我们的查询将始终具有完整的guid，可以将子字符串向下转换为shardkey值。当然，我可以使用API在事实发生后获取分布，因此我将标记为答案。我相信这个概率与我在更新中概述的大致相同。