我有一个基本的问题，我应该在mongo db中嵌入一组关注者/跟随者。在用户对象中嵌入一个嵌入式集合是有意义的，但同样嵌入逆向关注者集合也是有意义的吗？这意味着我必须更新并嵌入以下两者的简档记录中：
除非我以某种方式在某处保留事务或更新状态，否则我无法确保原子性。是否值得嵌入两个实体或者我应该更新＃1，嵌入跟随者的个人资料中，并在其上放置一个索引，以便我可以查询所有配置文件中的反向跟随者？性能是否受到太大影响？
这是否应该是不应该嵌入的集合的候选者？我是否应该只有一个边缘集合，我将其存储在自己的集合中，并使用followerid和followbyId？
现在，如果我必须在跟踪或关注两个用户时更新供稿，我应该如何组织它？
对于用例，用户在查看他们的Feed时会看到他们关注的人，这种情况经常发生，并且当他们查看任何人的个人资料详情时也会看到个人资料的关注者，这也经常发生但是不如第一种情况那么多。在这两种情况下，每个个人资料页面都会显示关注者和关注者的总数。
答案 0 :(得分：12)
一般而言，将跟随/跟随关系嵌入用户文档是一个坏主意，原因如下：
（1）最大文档大小限制为16MB，并且一个订阅良好的网站的热门用户可能最终会有数十万粉丝，这将接近最大文档大小，
（2）关注关系频繁变化，因此如果您嵌入关注者，用户获得大量关注者的情况会转化为重复的文档增长。频繁的文档增长将显着阻碍MongoDB的性能，因此应该避免（偶尔的文档增长，特别是文档往往达到稳定的最终大小，而不是性能损失）。
所以，是的，最好将跟随/跟随关系拆分为一个单独的记录集合，每个记录都有两个字段，例如{_id：，oid：}，索引在_id上（对于“谁是谁”）我跟着？“查询”和oid（对于“谁跟着我？”查询）。任何单独的状态更改都是通过单个文档添加或删除来建模的，但是如果您还显示跟随者计数之类的内容，则应该保留在任何边插入/删除之后更新的单独计数器。
（当然，这假设您的业务需求允许您在一致性详细信息上有一些灵活性：通常，如果您的显示代码告诉用户他有304个粉丝，然后继续枚举它们，只有最挑剔的用户才会检查如果业务需求必须绝对一致，那么你需要一个为你隔离事务的数据库，否则你必须自己进行计数，作为显示所有用户身份的一部分。）