41

我正在创建一个服务，我将使用 MongoDB 作为存储后端。该服务将生成用户输入的哈希，然后查看我们的数据集中是否已经存在相同的哈希（+ 输入）。

哈希将是唯一但随机的（=非增量/顺序），所以我的问题是：

  1. 对对象 ID 使用随机值是否合法？例子：

$object_id = new MongoId(HEX-OF-96BIT-HASH);

或者 MongoDB 是否会将 ObjectID 与其他服务器生成的对象区别对待，因为“真实”的 ObjectID 还包含时间戳、machine_id 等？

使用“随机”值的优缺点是什么？我想当新的_id不是以任何方式递增时，引擎更新插入索引的统计速度会更慢 - 我对此是否正确？

4

4 回答 4

48

是的，对对象 id 使用随机值是完全可以的，如果_id正在存储的文档的字段中存在某个值，则将其视为 objectId。

由于_id字段始终是索引的，并且是主键，因此您需要确保为每个对象生成不同的 objectid。有一些准则可以优化用户定义的对象 ID：

https://docs.mongodb.com/manual/core/document/#the-id-field。

于 2012-08-31T08:09:27.190 回答
12

虽然任何值（包括哈希）都可以用于该_id字段，但我建议不要使用随机值，原因有两个：

  1. 如果您为两个不同的对象生成相同的随机值，您可能需要制定碰撞管理策略。在问题中，您暗示您将使用某种类型的哈希算法生成 ID。我不会认为这些值是“随机的”，因为它们是基于您使用散列消化的内容。那么，冲突的概率是内容的多样性和散列算法的函数。如果您使用的是 MD5 或 SHA-1 之类的东西，我不会担心算法，只担心您正在散列的内容。如果您需要开发冲突管理策略，那么您绝对不应该使用随机或基于哈希的 ID，因为集群环境中的冲突管理很复杂并且需要额外的查询。

  2. 随机值和散列值有意分散在数轴上。(a) 将需要更多的 B-tree 索引始终保存在内存中，并且 (b) 由于 B-tree 重新平衡，可能会导致可变的插入性能。MongoDB 经过优化以处理 ObjectID，它按升序排列（以一秒时间粒度）。你可能最好还是坚持下去。

于 2012-09-03T01:26:13.787 回答
7

它的好坏取决于它的独特性。当然，MongoDB 提供的 ObjectId 非常独特，所以这是一件好事。只要您可以复制这种独特性，那么您应该没问题。

使用您自己的 ID 没有固有的风险/性能损失。我猜想以字符串形式使用它可能会消耗更多的索引/存储/查询能力，但是您在 MongoID (ObjectId) 形式中使用它应该保留不将其存储在简单字符串中的优势。

于 2012-08-31T08:12:04.877 回答
7

我刚刚找到了一个关于索引性能的问题的答案：

如果 _id 的顺序有些明确，则不需要加载 _id 索引的整个 b 树。BSON ObjectIds 有这个属性。

来源：http ://www.mongodb.org/display/DOCS/Optimizing+Object+IDs

于 2012-09-02T17:42:45.543 回答