mongo db 设计的关注和提要，我应该在哪里嵌入? [英] mongo db design of following and feeds, where should I embed?
问题描述
我有一个基本问题，关于我应该在哪里嵌入一组追随者/追随者到 mongo db.在用户对象中嵌入关注的集合是有意义的，但是也嵌入逆关注者集合是否也有意义?这意味着我必须更新并嵌入以下两者的个人资料记录:
I have a basic question about where I should embed a collection of followers/following in a mongo db. It makes sense to have an embedded collection of following in a user object, but does it also make sense to also embed the converse followers collection as well? That would mean I would have to update and embed in the profile record of both the:
- 跟随者中的嵌入列表
- 以及followee嵌入的followee列表
除非我还以某种方式在某处保留事务或更新状态，否则我无法确保其原子性.是否值得在两个实体中嵌入，或者我应该只更新#1，在关注者的个人资料中嵌入关注，然后在其上放置一个索引，以便我可以在所有个人资料中查询相反的关注者?对性能的影响是不是太大了?
I can't ensure atomicity on that unless I also somehow keep a transaction or update status somewhere. Is it worth it embedding in both entities or should I just update #1, embed following in the follower's profile and, put an index on it so that I can query for the converse- followers across all profiles? Is the performance hit on that too much?
这是不应该嵌入的集合的候选者吗?我是否应该只拥有一个边缘集合，在其中使用 followerid 和 followbyId 将关注存储在其自己的集合中?
Is this a candidate for a collection that should not be embedded? Should I just have a collection of edges where I store following in its own collection with followerid and followedbyId ?
现在，如果我还必须在两个用户被关注或关注时更新他们的提要，我应该如何组织呢?
Now if I also have to update a feed to both users when they are followed or following, how should I organize that?
至于用例，用户在查看他们的提要时会看到他们正在关注的人，这种情况经常发生，当他们查看任何人的个人资料详细信息时，也会看到个人资料的关注者，这也经常发生，但不如第一种情况多.在这两种情况下，关注者和关注者的总数都会显示在每个个人资料页面上.
As for the use case, the user will see the people they are following when viewing their feeds, which happens quite often, and also see the followers of a profile when they view the profile detail of anyone, which also happens often but not quite as much as the 1st case. In both cases, the total numbers of following and followers shows up on every profile page.
推荐答案
一般来说，在用户文档中嵌入跟随/跟随关系是个坏主意，原因如下:
In general, it's a bad idea to embed following/followed-by relationships into user documents, for several reasons:
(1) 最大文档大小限制为 16MB，一个订阅量大的网站的热门用户最终可能拥有数十万粉丝，这将接近最大文档大小，
(1) there is a maximum document size limit of 16MB, and it's plausible that a popular user of a well-subscribed site might end up with hundreds of thousands of followers, which will approach the maximum document size,
(2) 追随者关系经常变化，因此如果您嵌入追随者，用户获得大量追随者的情况会转化为重复的文档增长.频繁的文档增长会严重影响 MongoDB 的性能，因此应该避免(偶尔的文档增长，尤其是文档趋于达到稳定的最终大小，对性能的影响较小).
(2) followership relationships change frequently, and so the case where a user gains a lot of followers translates into repeated document growth if you're embedding followers. Frequent document growth will significantly hinder MongoDB performance, and so should be avoided (occasional document growth, especially is documents tend to reach a stable final size, is less of a performance penalty).
所以，是的，最好将跟随/被跟随关系拆分为单独的记录集合，每个记录具有两个字段，例如 { _id : , oid : }，索引在 _id 上(对于谁是我关注?"查询)和 oid(用于谁在关注我?"查询).任何单个状态更改都由单个文档添加或删除建模，但如果您还显示关注者计数等内容，您可能应该保留在任何边缘插入/删除后更新的单独计数器.
So, yes, it is best to split out following/followed-by relationship into a separate collection of records each having two fields, e.g., { _id : , oid : }, with indexes on _id (for the "who am I following?" query) and oid (for the "who's following me?" query). Any individual state change is modeled by a single document addition or removal, though if you're also displaying things like follower counts, you should probably keep separate counters that you update after any edge insertion/deletion.
(当然，这假设您的业务要求允许您在一致性细节上具有一定的灵活性:通常，如果您的显示代码告诉用户他有 304 个关注者，然后继续枚举他们，那么只有最挑剔的用户会检查追随者列举的总数高达 304.如果业务需求需要绝对一致性，您将需要一个为您隔离事务的数据库，否则您必须自己进行计数，作为显示所有用户身份的一部分.)
(Of course, this supposes your business requirements allow you some flexibility on the consistency details: in general, if your display code tells a user he's got 304 followers and then proceeds to enumerate them, only the most fussy user will check that the followers enumerated tally up to 304. If business requirements necessitate absolute consistency, you'll either need a database that isolates transactions for you, or else you'll have to do the counting yourself as part of displaying all user identities.)
这篇关于mongo db 设计的关注和提要，我应该在哪里嵌入?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
