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

Question

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

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

Answer 1

  

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

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

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

基本上，你最终会得到像

这样的架构

_id