哪种 MongoDB 方法在代码可读性和可扩展性方面更好？答案

【问题标题】：Which MongoDB approach is better for code readability and scalability?哪种 MongoDB 方法在代码可读性和可扩展性方面更好？
【发布时间】：2016-06-21 04:38:03
【问题描述】：

我有一个名为 User 的 MongoDB 文档，模型如下：

var User = mongoose.schema({
   _id: ObjectId,
   name: String,
   age: Number,
   blog_posts: [ObjectID]
});

还有一个名为 BlogPost 的文档，模型如下：

var BlogPost = mongoose.schema({
   _id: ObjectId,
   title: String,
   author: ObjectId,
   content: String,
   date: Date
});

现在假设这已扩展到 50,000 多个用户和 500,000 多个博客帖子。如果我想查找用户的博文，这将是一种更好的方法（就性能和代码可读性而言）：

Approach 1:
搜索所有BlogPost，找到匹配的author = ObjectId。

Approach 2:
仅搜索 BlogPost，其 ObjectId 与 User blog_posts 数组中的 ObjectId 匹配。

似乎这两种方法都需要搜索 BlogPost 的所有 100,000 多条记录。将ObjectId存储在Userblog_posts数组有什么好处？

【问题讨论】：

标签： mongodb mongoose nosql

【解决方案1】：

我对 mongodb 的经验是“避免”数组，如果你能做到以下两点：

Mongodb 存储引擎不喜欢快速增长的阵列，尤其是 MMAPv1。
很难对数组运行查询，尤其是嵌套数组。

在这种情况下，您可以完全忘记 user.brog_posts，因此请使用方法 1。在 BlogPost.author 上运行查询会更快、更容易，因为您不必使用聚合框架，并且可以在单个对象上比在数组上更有效地使用索引。

总而言之，如果您使用方法 1，它会更快且更难使用。

【讨论】：

很好，我希望是这样。你对我应该如何构建 MongoDB 有任何其他提示吗？我已经阅读了最佳实践，但绝对觉得我可以使用更多。
尽量避免深度嵌套的数组。如果您可以使用索引 100% 覆盖您的查询，那么您的结构就是正确的。例如，您不能索引不好的嵌套数组...尝试创建更多文档而不是嵌套。尽量避免关系，但它不被禁止聚合 $lookup 实际上非常快。基本上 mongodb 查询使用起来非常有趣。如果您在查询时感到痛苦，那么您做错了。
太棒了！非常感谢！