什么是良好的MongoDB文档结构,可以最有效地查询用户关注者/被关注者？

Question

我一直想知道理想的文档结构,以便在各种情况下获得最大的查询效率,并且我想问一下.在这种特殊情况下,我真的不知道MongoDB在内存中的表现如何.让我给你一个假设的场景.

想象一下Twitter风格的追随者和追随者系统.在粗略地看了一眼之后,主要选项似乎是:

1. 在每个用户文档中,"followers"数组包含对其遵循的其他用户的所有文档的引用.通过在其他用户的"user.followers"数组中查找我们当前的用户来找到被关注者.主要的缺点似乎是Followee搜索的潜在查询开销.此外,对于专门针对"user.followers"内容的查询,MongoDB是否只访问用户文档中的必填字段,或者是找到整个用户文档,然后从那里查找所需的字段值并将其缓存/以这样的方式存储,即对大型用户群的查询需要更多的内存？

2. 在每个用户文档中,存储"关注者"和"跟随者"以便更快地访问每个用户文档.这显然具有重复数据的缺点,即在用户B之后的用户A的条目存在于相应字段中的两个用户文档中,并且从中删除需要在另一个中的匹配删除.从技术上讲,这可能是考虑将简单删除的潜在失败点数加倍.当删除发生时,MongoDB是否仍然遭受我所听到的描述为"swiss cheesing"的内存存储数据,因此从2个字段中删除而不是1会使该内存空洞问题的影响加倍？

3. 用于存储用户关注者的单独集合,以与1-用户文档类似的方式查询,除了显然唯一访问的数据是关注者,因此如果用户文档包含与每个用户相关的大量其他数据,我们避免访问该数据.这似乎有一些关系数据库的感觉,虽然我知道在原则上并不总是一个糟糕的方法,显然如果提到的其他方法之一(或我没有考虑过)在Mongo的架构下更好我我喜欢学习!

如果有人对此有任何想法,或者想告诉我,我错过了一个非常相关且显而易见的文档页面,或者甚至想告诉我,我只是愚蠢(想到解释原因,请; ))我很想听到你的消息!

Answer 1

这是一个经典的跟随者 - 跟随者问题,并且没有人回答它.查看此链接:

mongo db设计的关注和提要,我应该在哪里嵌入？

实际上,如果MongoDB和SQL服务器是您唯一的选择,这种情况非常适合关系模式.但这是一种特殊的关系问题,你有双向关系.这可以通过图形数据库更好地处理:

http: //forum.kohanaframework.org/discussion/10130/followers-and-following-database-design-like-twitter/p1

问题是,你可以保留关注者或在用户文档中跟随,但不是两者,以避免双重删除问题.所以,如果你一定要坚持的MongoDB,一个出路可能是..(假设人不按照/停止追随任何人是经常),

只保留追随者的文档中,因为当我查看我的个人资料,我会很感兴趣我跟随的人......(这就是我首先跟随他们的原因,对吗？)然后做一个像这样的查询:

db.Users.find({ user_id : { $in : followees })

这将告诉所有人都跟着我(说我的id是'user_id').

我不建议反过来的另一个原因是...最多可以跟随30-40人,因此存储30-40个跟随者的用户文档应该可以存储,而不是存储数千个粉丝的用户文档!使用文档跟随方法,您可以获得大致均匀的用户文档.在文档跟随方法中,您将获得一些非常小但一些非常庞大的文档.根据您输入的关注者数据量(如果有的话,除了follower_id),您可能需要注意文档大小限制.