Twitter克隆的最佳MongoDB模式? [英] Best MongoDB schema for twitter clone?

问题描述

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

I know similar questions have been asked, but looking for a very basic answer to a basic question. I am new to MongoDB and making a twitter style app (blogs, followers, etc) and I'm wondering the best schema to use.

现在我(非常高的水平):

Right now I have (on a very high level):

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

还有更多的功能，但这给了您这个主意. 现在的问题是我要添加关注"功能，但是我不确定要走的最佳路线.

There is more to it, but that gives you the idea. Now the problem is I'm looking to add the "follow" feature and I'm not sure the best route to go.

我可以向会员"添加以下"嵌入式文档，但是我不确定使用mongoDB哪种最聪明的方法.我的主要想法显然是主要的供稿"页面，您可以在其中看到正在关注的所有人员.

I could add a "following" embedded doc to the Member, but I'm just not sure using mongoDB what the smartest method would be. My main concearn would obviously be the main "feed" page where you see all of the people you are following's posts.

推荐答案

对于Twitter克隆而言，这不是理想的架构.主要问题是"posts"是一个不断增长的数组，这意味着mongo必须每隔几条posts就移动一次庞大的文档，因为它用完了文档填充.此外，文档有一个严格的(16mb)大小限制，这使得此架构最多只能是限制性的.

This is not an ideal schema for a Twitter clone. The main problem is that "posts" is an evergrowing array which means mongo will have to move your massive document every few posts because it ran out of document padding. Additionally there's a hard (16mb) size limit to documents which makes this schema restrictive at best.

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

The ideal schema depends on whether or not you expect Twitter's load. The "perfect" mongodb schema in terms of maintainability and easy of use is not the same as the one I'd use for something with Twitter's throughput. For example, in the former case I'd use a posts collection with a document per post. In the high throughput scenario I'd start making bucket documents for small groups of posts (say, one per "get more" page). Additionally in the high throughput scenario you'd have to keep the follower's timeline up to date in seperate user timeline documents while in low throughput scenarios you can simply query them.

这篇关于Twitter克隆的最佳MongoDB模式?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！