在mongo中使用slug作为主键/_id的性能劣势？

Question

让我们以一篇博客文章为例，该文章的标题生成了一个独特的 slug：sample_blog_post。假设您将 slug 存储在 _id 中，而不是将 mongo ObjectId 存储为 _id。除了标题更改时 slug 可能会更改的明显情况之外，使用字符串而不是数字 _id 在性能方面是否存在主要缺点？如果帖子数量变得非常大，例如超过一百万，这可能会成为问题。但如果帖子数量相对较少，比如 2000 个，会有很大的不同吗？到目前为止，我认为我会利用的关于 ObjectId 的唯一一点是 created_on 日期，它是免费提供的。

总而言之，将 slug 存储为 _id 而不使用 ObjectId 是否值得？似乎有关于如何将替代值存储为 _id 的讨论，但没有讨论它的性能优势/劣势。

Answer 1

总而言之，将 slug 存储为 _id 而不使用 ObjectId 是否值得？

在我看来，没有。对于大多数场景（分页除外），性能差异可以忽略不计，但

• 关于代理主键的旧讨论出现了。 “蛞蝓”不是很自然的钥匙。是的，它必须是独一无二的，但正如您已经指出的那样，改变蛞蝓应该不是不可能的。仅此一项就不会打扰我了...
• 拥有一个单调的_id 键可以使您免于许多麻烦，最重要的是避免通过skip 和take 进行昂贵的分页（在_id 上使用$lt/$gt 代替）。
• maximum index length in mongodb 有一个小于 1024 字节的限制。虽然不漂亮，但 URL 可以是 a lot longer。如果有人输入了更长的 slug，则不会被找到，因为它会从索引中静默删除。
• 最好有一个一致的界面，即在所有或至少大部分对象上使用相同类型的_id。在我的代码中，我有一个例外，我使用特殊的哈希作为 id，因为值不能改变，集合具有极高的写入率并且很大。
• 假设您想在管理界面（不是公共站点）中链接到文章，您会使用哪个链接？通常是 id，但现在 id 和 slug 是等价的。现在，一个简单的错误（例如允许空 slug）将很难恢复，因为用户甚至无法再进入管理界面。
• 您将处理字符集问题。我建议不要使用 slug 来查找文章，而是使用 slug 的 hash。

基本上，您最终会得到类似的架构

{ "_id" : ObjectId("a237b45..."), // PK
  "slug" : "mongodb-is-fun", // not indexed
  "hash" : "5af87c62da34" } // indexed, unique