假设我有一个名为的集合Articles.如果我要在不为_id字段提供值的情况下将新文档插入到该集合中,MongoDB将为我生成一个特定于该机器和操作时间的文档(例如sdf4sd89fds78hj).
但是,我确实能够传递MongoDB的值作为_id键的值(例如1).
我的问题是,使用我自己的自定义有什么好处_id,或者最好让Mongo做它的事情?在什么情况下我需要分配自定义_id?
更新
对于其他可能发现这一点的人.一般的想法(据我所知)是分配你自己的_ids 并没有错,但是它会强迫你在你的应用层(PITA)中维护唯一的值,并且每次都要求额外的查询insert以确保你不要不小心复制了一个值.
Sammaye在这里提供了一个很好的答案: 将MongoDB中的_id类型更改为整数是不是很糟糕?
生成自己的_ids 的优势:
1, 2, 3, ...t3oSKd9q使用ObjectIds 的优点:
ObjectIds 非常擅长避免冲突。如果您生成自己的_ids,那么您需要自己管理碰撞风险。
ObjectIds 包含它们的创建时间。这是保留文档创建日期和按时间顺序对文档进行排序的一种廉价且简单的方法。(另一方面,如果您不想公开/泄露文档的创建日期,则不得公开其 ObjectId!)
该nanoid模块可以帮助您生成短随机编号。他们还提供了一个计算器,可以帮助您选择合适的 id 长度,具体取决于您每小时生成的文档/id 数量。
或者,我编写了mongoose-generate-unique-key来生成非常短的随机 ID(前提是您使用的是 mongoose 库)。
我可以想到一个预先生成您自己的 ID 的充分理由。那是为了幂等性。例如,可以在崩溃后判断某些东西是否有效。当使用重试逻辑时,此方法效果很好。
\n\n让我解释。人们可能考虑重试逻辑的原因是:\n应用程序间通信有时可能会因不同原因而失败(尤其是在微服务架构中)。通过将应用程序编码为重试而不是立即放弃,该应用程序将更具弹性和自我修复能力。这会克服可能发生的奇怪现象,而消费者却不会受到影响。
\n\n例如,在处理 mongo 时,向数据库发送一个请求来存储某个对象,数据库保存了它,但正当它试图响应客户端说一切正常时,由于某种原因出现了网络故障,从未收到 \xe2\x80\x9cOK\xe2\x80\x9d。该应用程序假设它不起作用,因此该应用程序最终可能会重新尝试相同的数据并将其存储两次,或更糟糕的是它会崩溃。
\n\n预先创建 ID 是一种简单、低开销的方法,有助于处理重试逻辑。当然也可以想到其他方案。
\n\n尽管这种弹性在某些类型的项目中可能有些过大,但这实际上取决于情况。
\n有时,ID 比随机生成的 ID 更有意义。例如,用户集合可以使用电子邮件地址作为 _id。在我的项目中,我生成的 ID 比 Mongodb 使用的 ID 短得多,因此 URL 中显示的 ID 也短得多。