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中匹配数组的各个部分...做出选择。

不再进一步了，因为如上所述：在关于“架构设计”的众多问题中已经讨论了同样的问题。只需谷歌“架构设计MongoDB”或在SO上寻找相同的内容。

Answer 3

将“follow”数组添加到Member文档应该可以正常工作。它应包含该成员所关注的人员的用户ID。您的代码必须检索列表并构造一个查询，以检索这些用户的推文。由于Mongo是非关系的，因此无法构造连接Member和Tweet集合的查询并在单个查询中执行此操作，但您应该能够通过使用服务器端代码执行在数据库服务器上执行此操作来减少网络开销：http://www.mongodb.org/display/DOCS/Server-side+Code+Execution。

Twitter克隆的最佳MongoDB架构？

3 个答案: