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