【发布时间】:2013-04-16 04:21:14
【问题描述】:
存储在每个文档的 _id 字段中的自动生成的 BSON ID,它是 GUID 吗? 文档说它“最有可能是独一无二的”,所以我有点困惑。为什么他们会使用不能保证唯一的 id?
【问题讨论】:
-
它保证是独一无二的,至少我从未见过真正的碰撞。有大量关于它的编码内容的文档。
-
即使 GUID 也不能保证其唯一性,但它们形成的方式可能始终是唯一的。
存储在每个文档的 _id 字段中的自动生成的 BSON ID,它是 GUID 吗? 文档说它“最有可能是独一无二的”,所以我有点困惑。为什么他们会使用不能保证唯一的 id?
【问题讨论】:
它在大多数需求中都是唯一的,它由时间戳、机器的唯一标识符(机器主机的哈希)、进程标识符和最后的增量编号组成。 http://docs.mongodb.org/manual/reference/object-id/
【讨论】:
ObjectId 在文档here 中进行了解释。它不是“保证”是唯一的,因为 MongoDB 不强制唯一性来节省时间。它只是相信复杂的生成算法可能永远不会在同一个数据存储中生成两个相同的 ObjectId。所以从技术上讲,它不是一个 GUID,但几乎一样好。
【讨论】:
它的唯一性是基于概率的。不像@mattexx 答案:
没有“保证”是唯一的,因为 MongoDB 不强制唯一性来节省时间。
MongoDB 确实在 ObjectId 上强制执行唯一性,它实际上在 _id 字段上具有唯一索引。在谈到节省时间时,ObjectId 以这种方式具有历史意义,因为它是在 MongoDB 没有确认任何写入的时代设计的,并且需要 99% 的机会能够插入新的唯一记录而无需客户端等待ack(ObjectIds 是在客户端生成的)。
它们不是 GUID,但正如 @Asya 所说,它们保证具有高水平的唯一性。
只要时间永不倒退,它仍有 99% 的机会永远独一无二。好的,正如@Devesh 所说,有 1 万亿分之一(?还没有计算过),甚至 GUID 也有可能被复制,但我不认为你会很快达到这个概率。
【讨论】:
ID 冲突的可能性理论上足够接近于零,可以假定为典型的网络应用程序。许多现实世界的系统(Mongo 与否)确实依赖于 GUID 的这一属性,尽管对于安全/关键任务系统来说这不是一个好的假设。
在实际方面,确实存在如果配置错误或第三方库错误可能会出错的情况。这些不应该排除这个概念,但重要的是要意识到这些风险并尽可能避免它们。
一些good analysis here 可能导致碰撞的实际问题。特别是:
一些 Mongo 驱动程序使用随机数而不是递增数作为计数器字节。在这些情况下,有 1/16,777,216 的机会生成非唯一 ID,但前提是这两个 ID 在同一秒内(即在 ID 的时间段更新到下一秒之前),在同一时间机器,在同一个过程中。
【讨论】: