9

我知道有人问过类似的问题，但正在寻找一个基本问题的非常基本的答案。我是 MongoDB 的新手，正在制作一个 twitter 风格的应用程序（博客、关注者等），我想知道要使用的最佳模式。

现在我有（在一个非常高的水平）：

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

还有更多，但这给了你这个想法。 现在的问题是我正在寻找添加“跟随”功能，但我不确定最佳路线。

我可以向成员添加一个“以下”嵌入式文档，但我只是不确定使用 mongoDB 最聪明的方法是什么。我的主要关注点显然是主要的“提要”页面，您可以在其中看到所有您关注的人的帖子。

4

3 回答 3

11

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

理想的模式取决于您是否期望 Twitter 的负载。就可维护性和易用性而言，“完美”的 mongodb 模式与我用于 Twitter 吞吐量的模式不同。例如，在前一种情况下，我会使用一个帖子集合，每个帖子都有一个文档。在高吞吐量场景中，我会开始为小组帖子制作存储桶文档（例如，每个“获取更多”页面一个）。此外，在高吞吐量场景中，您必须在单独的用户时间线文档中保持关注者的时间线是最新的，而在低吞吐量场景中，您可以简单地查询它们。

于 2011-06-29T13:59:25.887 回答
0

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

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

利弊已被广泛讨论。嵌入式文档只能是 16MB 大，并且无法在 MongoDB 中返回匹配数组的各个部分......做出你的选择。

不再赘述，因为如前所述：在许多关于“模式设计”的问题中都讨论了同样的问题。只需谷歌“Schema Design MongoDB”或在 SO 上查找相同的内容。

于 2011-06-29T04:57:06.757 回答
0

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

于 2011-06-29T05:34:15.330 回答