本地UUID vs网络唯一计数器ID

Question

您会选择哪一个作为代理密钥实施？

• 本地UUID
  • 这是在应用程序中本地生成的，没有网络旅行来检索它
  • 但长度很长，可能会影响存储空间大小的使用
  • 长UUID的冗长网址
  • UUID碰撞最微小的恐惧
• 或..网络唯一计数器ID（不确定什么是适当的术语）
  • 我想象一个远程Redis与原子INC或Mongo与$ inc
  • 网络旅行的费用
  • 更短，占用更少的空间并导致更短的网址
  • 即使在群集应用程序上也不用担心碰撞

Answer 1

如果您使用的是MongoDB，则应考虑使用BSON ObjectID：

http://www.mongodb.org/display/DOCS/Object+IDs

默认情况下，它们是作为_id字段创建的，除非您另行指定并自己创建_id字段（也可以是由您创建的ObjectID）。不用担心碰撞，您可以在数据库中获得本机支持的ID类型，您也可以在应用程序中使用它。看似双赢，只要你当然使用MongoDB;）

Answer 2

您可以结合使用这两种方法。看看twitter的SnowFlake算法。该算法将产生全局唯一整数（64位），但没有任何协调，纯粹的本地算法。

Answer 3

对于低并发应用，您可以使用网络计数器ID。 但除了url之外，对低并发性没有兴趣（=不是很多数据）。

在大量并发访问的情况下，所以很多数据，所以很多集群，你redis引擎+关联网络可能会为这个解决方案慢。

总结： - 使用MongoDB，网络计数器似乎性感但无用，在我看来。

在MongoDB碰撞中，由于创建算法，碰撞几乎为零。我解释一下，uuid的一部分是使用机器地址构建的，它应该是唯一的，您可以在将集群投入生产之前获取此地址。