mongo db设计了以下和feed,我应该在哪里嵌入？

Question

我有一个基本的问题,我应该在mongo db中嵌入一组关注者/跟随者.在用户对象中嵌入一个嵌入式集合是有意义的,但同样嵌入逆向关注者集合也是有意义的吗？这意味着我必须更新并嵌入以下两个的配置文件记录中:

1. 跟随者中的嵌入列表
2. 并且追随者嵌入了跟随者的列表

除非我以某种方式在某处保留事务或更新状态,否则我无法确保原子性.是否值得嵌入两个实体或者我应该更新#1,嵌入跟随者的个人资料中,并在其上放置一个索引,以便我可以查询所有配置文件中的反向跟随者？性能是否受到太大影响？

这是不应该嵌入的集合的候选者吗？我是否应该只有一个边缘集合,我将其存储在自己的集合中,并使用followerid和followbyId？

现在,如果我必须在跟踪或关注两个用户时更新供稿,我应该如何组织它？

至于用例,用户在查看他们的Feed时会看到他们正在关注的人,这种情况经常发生,并且当他们查看任何人的个人资料详细信息时也会看到个人资料的关注者,这也经常发生但不完全如同就像第一例一样.在这两种情况下,每个个人资料页面上都会显示关注者和关注者的总数.

Answer 1

通常,将跟随/跟随关系嵌入到用户文档中是一个坏主意,原因如下:

(1)最大文档大小限制为16MB,并且一个订阅良好的站点的热门用户可能最终会有数十万个关注者,这将接近最大文档大小,

(2)关注关系频繁变化,因此如果您嵌入关注者,用户获得大量关注者的情况会转化为重复的文档增长.频繁的文档增长将显着阻碍MongoDB的性能,因此应该避免(偶尔的文档增长,特别是文档往往达到稳定的最终大小,而不是性能损失).

所以,是的,最好将跟随/跟随关系分成一个单独的记录集合,每个记录都有两个字段,例如{_id:,oid:},索引在_id上(对于"我是谁？ "查询"和oid(对于"谁跟着我？"查询).任何单独的状态更改都是通过添加或删除单个文档来建模的,但如果您还要显示跟随者计数之类的内容,则应该保留在任何边插入/删除之后更新的单独计数器.

(当然,这假设您的业务需求允许您在一致性详细信息上有一些灵活性:通常,如果您的显示代码告诉用户他有304个粉丝然后继续枚举它们,那么只有最挑剔的用户才会检查跟随者是否枚举如果业务需求需要绝对一致,那么您需要一个为您隔离事务的数据库,否则您将需要自己进行计数,以显示所有用户身份.)