MongoDB：如何在 MongoDB 中设计 Twitter 风格的关注者/关注者关系模型？答案

【问题标题】：MongoDB: How to design twitter-style followers/following relation model in MongoDB?MongoDB：如何在 MongoDB 中设计 Twitter 风格的关注者/关注者关系模型？
【发布时间】：2013-01-22 13:02:14
【问题描述】：

我正在开发一个可能拥有大量用户（假设大约 100 万）的 Android 移动应用。这些用户可以关注其他用户（如 Twitter）。该应用程序通过远程 REST 后端同步用户数据。用户数据本身保存在面向文档的数据库中（在我的例子中是 MongoDB）。

目前我问自己设计用户模型的最佳方式，包括其追随者和追随关系。首先想到的是在用户文档中嵌入关系。

用户文档示例：

{
"_id":"50fd6bb530043e3c569af288", 
"name":"Marsha Garcia", 
"follower"["50fd6bb530043e3c569af287","50fd6bb530043e3c569af289","50fd6bb530043e3c569af28c"],
"following":["70fd6bb530043e3c569af289","10fd6bb530043e3c569af222","89fd6bb530043e3c569af45o"]
}

积极的一面是关注/关注关系已经与用户连接。但是，假设一个用户关注了大约 100.000 个或更多其他用户。然后文档大小会变得非常大。如果我通过移动应用程序中的 REST 服务加载此用户对象，可能需要一段时间。此外，在最坏的情况下，用户文档可能会超过 MongoDb 的 16MB 文档限制。

因此我的第二个想法是以更经典的方式对关注者和关注者关系进行建模：一个包含每个用户的关注者关系的额外文档。

“用户关系”文档示例：

{
    "_id": 50fe65828de290c0a8a8ea2d"
    "uid": "50fd6bb530043e3c569af288",
    "rel_uid": "50fe65828de290c0a8a8e9a6",
    "type": "FOLLOWING"
}

积极的一面是每个用户文档的大小将保持不变。缺点是有很多用户和关注关系，我可以很容易地在我的 MongoDB“用户关系”集合中获得数百万个条目。当然，我会在字段上设置一个索引，但我不太确定这个解决方案是否能很好地适应应用用户询问他/她当前关注者的用例。

如果对我的建模问题有任何想法和经验，我将不胜感激。也许有人甚至有更好的解决方法。

提前致谢。

【问题讨论】：

换个思路，你将如何在移动设备上显示 100 万关注者列表？
当然，我不会一次将它们全部展示出来。可能我会使用分页机制。例如加载前 50 个关注者。如果用户希望看到更多加载下 50 个关注者等等。

标签： android mongodb mobile mongodb-java

【解决方案1】：

1. collection users:
- userid
- username
- userpass
- other user specific info user


2. collection following:
- userid
- [array of followingid]


3. collection followed:
- userid
- [array of followedid]
4. messages_relation collection:

- userid
- messageid
- time

5. messages_text:
- messageid
- text

【讨论】：

谢谢不错。这样我就可以避免使用大尺寸的用户文档。但是在特殊情况下，我仍然可以拥有大型“关注”文档，但我必须选择较小的邪恶；）
这是正常模式。如果你有很多用户，你必须为一些集合创建分片。
我还没有阅读太多关于 MongoDB 分片概念的内容。但我想我现在必须做;)
如果真的变大的话，每个文档仍然会遇到 16mb 的问题
为什么要将消息文本与 messages_relation 分开？用于节省磁盘？如果消息文本存储在同一个集合中，效率会更高。将减少一次数据库访问。

【解决方案2】：

如果您还没有阅读有关在 CMS 中存储 cmets 的文档，我会先阅读 this 文档。虽然它适用于 cmets，但存在同样的普遍问题 - 您无法将所有 cmets 存储在单个文档中（在您的情况下，关注者/关注者）。

混合方法（使用较少的文档并在单个文档中存储一些关系）或您描述的方法都应该很好用。

我还建议构建一个简单的 POC 来测试检索等的性能。缓存一些结果或预编译它们可能是有意义的。通常，在这样的系统中，如果所有用户的所有内容都不能立即保持一致（比如让追随者数量立即正确），这是可以的。

可能没有完美的解决方案，可能需要一些解决方案才能获得最佳性能（例如，处理用户和关注者的方式可能会随着关注者数量的增加而改变）。

【讨论】：

感谢文档链接很有帮助。你是对的，可能没有完美的解决方案。我想用一些测试数据尝试不同的方法。可能 MongoDb 投影和切片机制也会有所帮助。

【解决方案3】：

您可能需要检查flockDB 一个存储邻接列表的数据库。 https://github.com/twitter/flockdb

【讨论】：