我有一个基本的问题，关于我应该在mongo db中嵌入跟随者/跟随者的集合。在用户对象中具有嵌入式关注集合是有意义的，但是也将相反的关注者集合也嵌入也有意义吗？这意味着我将不得不更新并嵌入以下两个的配置文件记录中:
除非我也以某种方式保留事务或更新状态，否则我无法保证原子性。将其嵌入两个实体中是否值得？还是我应该更新＃1，在关注者的个人资料中嵌入以下内容，并在其上添加索引，以便我可以查询所有个人资料中的反向关注者？性能受到的冲击太大了吗？
这是不应该嵌入的集合的候选人吗？我是否应该只收集一个边缘集合，在其中使用followerid和followedIdId将关注存储在其自身的集合中？
现在，如果在跟随或跟随这两个用户的同时还必须更新两个用户的供稿，我应该如何组织它们？
至于用例，用户在查看提要时会看到他们关注的人，这很常见；在查看任何人的个人资料详细信息时，用户也会看到个人资料的追随者，这种情况也经常发生，但不完全是和第一种情况一样。在这两种情况下，每个个人资料页面上都会显示关注者和关注者的总数。
最佳答案
通常，出于以下几个原因，将跟随/跟随的关系嵌入到用户文档中是一个不好的主意:
(1)最大文件大小限制为16MB，一个订阅良好的网站的受欢迎用户最终可能会获得成千上万的关注者，这将接近最大文件大小，
(2)追随者关系经常变化，因此，如果您嵌入追随者，那么用户获得大量追随者的情况将转化为重复的文档增长。频繁的文档增长将严重阻碍MongoDB的性能，因此应避免(偶尔的文档增长，尤其是文档趋于达到稳定的最终大小，对性能的影响较小)。
因此，是的，最好将跟随/跟随关系分解为一个单独的记录集合，每个记录具有两个字段，例如{_id:，oid:}，并且在_id上具有索引(对于“我关注谁？” ”和oid(用于“谁在关注我？”查询)。任何单独的状态更改都是通过单个文档的添加或删除来建模的，尽管如果您还显示跟随者计数之类的内容，则可能应保留单独的计数器，这些计数器在插入/删除任何边后都会更新。
(当然，这是假设您的业务需求允许您在一致性详细信息上有一定的灵活性:通常，如果您的显示代码告诉用户他有304个关注者，然后继续枚举他们，则只有最挑剔的用户才会检查该关注者是否为枚举总计到304。如果业务需求需要绝对的一致性，那么您将需要一个数据库来为您隔离事务，否则您将不得不在计算所有用户身份时对自己进行计数。)
关于mongodb - mongodb的关注和提要设计，我应该在哪里嵌入？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/8213637/