mongodb - 对于最有效地查询用户关注者/被关注者来说，什么是好的 MongoDB 文档结构？

Question

我一直想知道在各种情况下如何实现最大查询效率的理想文档结构，我想询问一个问题。这确实是因为我并不真正了解 MongoDB 在这种特定情况下在内存中的表现。让我给你一个假设的场景。

想象一下 Twitter 风格的关注者和关注者系统。经过粗略浏览后，主要选项似乎是:

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

2. 在每个用户文档中，存储“关注者”和“关注者”，以便更快地访问每个用户。这显然具有重复数据的缺点，因为用户 A 跟随用户 B 的条目存在于相应字段的两个用户文档中，并且从 from 中删除需要在另一个中进行匹配删除。从技术上讲，这可能会考虑将简单删除的潜在故障点数量加倍。当删除发生时，MongoDB 是否仍然遭受我所听到的内存存储数据的“瑞士奶酪”的困扰，因此从 2 个字段而不是 1 个字段中删除会使内存漏洞问题的影响加倍？

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

如果有人对此有任何想法，或者想告诉我我在某个地方错过了一个非常相关且明显的文档页面，或者甚至想告诉我我只是很愚蠢(思考并解释为什么，拜托；))我很想听听您的意见!

Answer 1

这是一个经典的关注者-关注者问题，没有一个答案。.查看此链接:

mongo db design of following and feeds, where should I embed?

实际上，如果 MongoDB 和 SQL Server 是您唯一的选择，那么这种情况非常适合关系模式。但这是一种特殊类型的关系问题，其中存在双向关系。这也许可以通过图形数据库更好地处理:

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)，您可能需要注意文档大小限制。