使用MongoDB使用自定义_id有什么好处吗？

Question

假设我有一个名为Articles的集合。如果我要在不为_id字段提供值的情况下将新文档插入到该集合中，MongoDB将为我生成一个特定于机器和操作时间的文档（例如sdf4sd89fds78hj） 。

但是，我确实可以传递MongoDB的值作为_id键的值（例如1）。

我的问题是，使用我自己的自定义_id有什么好处，或者最好让Mongo做它的事情？在什么情况下我需要分配自定义_id？

更新

对于其他可能发现此事的人。一般的想法（据我所知）是分配你自己的_id没有什么问题，但是它会强迫你在你的应用层（PITA）中维护唯一的值，并且每次都需要额外的查询。 insert以确保您不会意外复制值。

Sammaye在这里提供了一个很好的答案： Is it bad to change _id type in MongoDB to integer?

Answer 1

有时，ID比随机生成的ID更有意义。例如，用户集合可以使用电子邮件地址作为_id。在我的项目中，我生成的ID比Mongodb使用的ID短得多，因此URL中显示的ID要短得多。

Answer 2

我多次使用自定义ID，这非常有用。

特别是我有一个集合，我按日期存储统计数据，因此_id实际上是特定格式的日期。我这样做主要是因为我总是按日期查询。请记住，使用此方法可以简化索引，因为不需要额外的索引，基本光标就足够了。

Answer 3

生成自己的_id s：

的优势

• 您可以通过指定递增数字来使它们更加人性化：1，2，3，...
• 或者您可以使用随机字符串使其更加人性化：t3oSKd9q
• 如果使用随机生成的字符串，它们将具有比标准mongo ObjectIds更好的分片分布，后者倾向于将同时创建的记录分组到同一个分片上。 （这是否有用真的取决于你的分片策略。）

使用ObjectId的优点：

• ObjectIds非常擅长避免碰撞。如果您生成自己的_id，那么您需要自己管理碰撞风险。

• ObjectIds包含其中的创建时间。这可以是保留文档创建日期以及按时间顺序对文档进行排序的便宜而简单的方法。 （另一方面，如果您不想公开/泄露文档的创建日期，则不得公开其ObjectId！）

nanoid模块可以帮助您生成短随机ID。它们还提供calculator，可以帮助您选择一个好的ID长度，具体取决于您每小时生成的文档/ ID数量。

我还写了module来生成非常短随机ID。

Answer 4

我可以想到一个很好的理由来预先生成自己的ID。那是为了幂等。例如，可以判断出崩溃后某些东西是否起作用。使用重试逻辑时，此方法效果很好。

让我解释一下。人们可能会考虑重试逻辑的原因： 应用程序间通信有时可能因各种原因而失败（尤其是在微服务架构中）。通过对应用进行重新编码，而不是立即放弃，该应用将具有更大的弹性和自我修复能力。这可以避免在不影响消费者的情况下可能发生的异常现象。

例如，在处理mongo时，一个请求被发送到数据库以存储一些对象，数据库将其保存，但是正如它试图响应客户端以说一切正常时，存在一个网络闪烁无论出于什么原因，都不会收到“确定”。该应用程序假设它无法正常工作，因此该应用程序可能最终会重试相同的数据并将其存储两次，或者更糟的是它会崩溃。

预先创建ID是一种轻松，低开销的方法，有助于处理重试逻辑。当然，人们也可以想到其他方案。

尽管这种弹性在某些类型的项目中可能会过大，但实际上取决于情况。