Mongodb:关于性能和模式设计

Question

在了解了 MongoDB 中的性能和模式设计之后，我仍然无法弄清楚当性能是必须的时，我将如何在应用程序中进行模式设计。

让我们想象一下，如果我们必须让 YouTube 使用 MongoDB 作为其数据库。您将如何制作架构？

选项 1:两个集合(视频集合和评论集合)

优点:添加、删除和编辑评论只会影响评论集合，因此这些操作会更有效率。

缺点:检索视频和评论是对数据库的两种不同查询，一种用于视频，一种用于评论。

选项 2:单个集合(嵌入评论的视频集合)

优点:您可以通过一次查询检索视频及其评论。

缺点:添加、删除和编辑评论会影响视频文档，因此这些操作会降低效率。

那你怎么看？我的猜测是真的吗？

Answer 1

作为沙漠中的调用者，不得不说embedding只应该在非常特殊的情况下使用:

1. 该关系是“一对(-非常)-少数”关系，并且绝对可以肯定没有文档会超过此限制。一个很好的例子是“用户”和“电子邮件地址”之间的关系——一个用户不太可能拥有数百万个用户，甚至人为限制也不存在问题:设置用户可能需要的最大地址数量，说 50 几乎不会引起问题。一个视频可能不太可能获得数百万条评论，但您不想对其施加人为限制，对吧？
2. 更新不经常发生。如果文档的大小增加超过某个阈值，它们可能会被移动，因为文档保证永远不会碎片化。但是，文档迁移代价高昂，您希望避免它们。
3. 基本上，对评论的所有操作都变得更加复杂，因此成本也更高——这是一个糟糕的选择。亲吻!

我写了an article about the above ，其中更详细地描述了各自的问题。

此外，我看不出对视频发表评论有任何好处。要回答的问题是

1. 对于给定的用户，视频是什么？
2. 最新的视频(带有特定标签)是什么？
3. 对于给定的视频，评论是什么？

请注意，此处视频和评论之间的唯一联系是关于给定的视频，因此您已经拥有 _id 或其他可以明确识别该视频的内容。此外，您不希望一次加载所有评论，尤其是当您有很多评论时，因为加载时间长会降低用户体验。

假设它是 _id。因此，有了它，您就可以轻松地分页评论:

db.comments.find({"video_id": idToFind})
.skip( (page-1) * pageSize )
.limit( pageSize )

第一个