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

Question

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

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

Answer 1

So in summation, is it worth it to store the slug as the _id and not use an ObjectId?

在我看来，没有。对于大多数情况(分页除外)，性能差异可以忽略不计，但是

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

从本质上讲，您最终会得到这样的架构

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