Twitter克隆的最佳MongoDB架构？

Question

我知道有类似的问题,但寻找一个基本问题的基本答案.我是MongoDB的新手,并制作了一个Twitter风格的应用程序(博客,粉丝等),我想知道最好使用的架构.

现在我(在很高的水平上):

Member {
  login: string,
  pass: string,
  posts: [
    {
      title: string,
      blog: string,
      comments: [ { comment: string } ]
    }
  ]
}

还有更多,但这给你的想法. 现在问题是我想添加"跟随"功能,我不确定最佳路线.

我可以向成员添加一个"跟随"嵌入式文档,但我不确定使用mongoDB最聪明的方法是什么.我的主要内容显然是主要的"提要"页面,您可以在其中看到您关注的所有人的帖子.

Answer 1

这不是Twitter克隆的理想架构.主要的问题是"帖子"是一个不断增长的数组,这意味着mongo必须每隔几个帖子移动你的大量文档,因为它用完了文档填充.此外,文档的大小限制为硬(16mb),这使得该模式充其量只是限制性的.

理想的架构取决于您是否期望Twitter的负载.在可维护性和易用性方面,"完美"的mongodb架构与我用于Twitter的吞吐量的东西不同.例如,在前一种情况下,我会使用一个帖子集合,每个帖子都有一个文档.在高吞吐量场景中,我开始为小组帖子制作存储桶文档(例如,每个"获取更多"页面一个).此外,在高吞吐量方案中,您必须在单独的用户时间线文档中保持跟随者的时间线是最新的,而在低吞吐量情况下,您可以简单地查询它们.

Answer 2

这个问题与博客文章示例中如何广泛使用以及如何对博客文章和评论进行建模的问题相同。您只需在这里应用相同的概念即可。您有以下选择：

• 嵌入文档
• 专用集合并执行多个查询

其优点和缺点已被广泛讨论。嵌入式文档只能有 16MB 大，并且不可能返回 MongoDB 中匹配数组的各个部分...做出您的选择。

不再进一步，因为如上所述：同一问题已在有关“模式设计”的许多问题中讨论过。只需谷歌“Schema Design MongoDB”或在 SO 上寻找相同的内容即可。