考虑到UUID rfc 4122（16字节）比MongoDB ObjectId（12字节）大得多，我试图找出它们的碰撞概率如何进行比较。
我知道这种情况不太可能出现，但是就我而言，大多数ID都是在大量移动客户端中生成的，而不是在一组有限的服务器中生成的。我想知道在这种情况下是否有正当理由。
与通常情况下，所有ID由少量客户端生成的情况相比：
就我而言，大多数ID是在大量移动客户端中生成的，而不是在一组有限的服务器中生成的。我想知道在这种情况下是否存在正当理由。
对我来说，这听起来很糟糕。您是否使用两层体系结构？为什么移动客户端可以直接访问数据库？您真的要依靠基于网络的安全性吗？
无论如何，对碰撞概率的一些思考：
UUID和ObjectId都不依赖于它们的绝对大小，即两者都不是随机数，但是它们遵循试图系统地降低冲突概率的方案。对于ObjectId，其结构为：
这意味着，与UUID相反，ObjectId是单调的（在一秒钟内除外），这可能是它们最重要的属性。单调索引将使B树的填充效率更高，它允许按id进行分页，并允许按id进行“默认排序”以使光标稳定，当然，它们还带有易于提取的时间戳。这些是您应该意识到的优化，它们可能是巨大的。
从其他3个组件的结构中可以看出，如果您在单个进程中执行> 1k次插入/秒（这实际上是不可能的，甚至不是来自服务器），冲突很有可能发生，或者如果计算机数量增加超过大约10（请参阅生日问题），或者单台计算机上的进程数过大（然后又不是随机数，但它们在计算机上确实是唯一的，但必须缩短到两个字节） ）。
自然，要发生冲突，它们必须在所有这些方面都匹配，因此，即使两台机器具有相同的机器哈希，它仍然需要客户端在完全相同的第二秒和相同的过程中插入相同的计数器值id，但是是的，这些值可能会冲突。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句