如何在 MongoDB 中对高度相关的数据进行建模答案

【问题标题】：How to model highly relational data in MongoDB如何在 MongoDB 中对高度相关的数据进行建模
【发布时间】：2020-10-01 08:12:34
【问题描述】：

我在 MongoDB 中的数据建模存在问题。文档似乎没有提出适合我的解决方案。

我的特定用例与 Facebook 好友系统非常相似。 我收藏了用户和每个用户都可以通过发送接受或拒绝的邀请与其他用户联系。这种机制将成为其他功能的基础，例如计算共同朋友、推荐最合适的朋友等。

看似流行的解决方案是：

在用户文档中将好友的 ID 作为数组嵌入
将好友数据作为数组嵌入到用户文档中

但是这是有问题的 - 如果某人有几千个朋友，那么性能就会受到影响，而性能对我来说很重要。

我的想法是创建单独的集合，其中每个文档都是两个用户之间的连接。该文档可能包含每个用户的嵌入数据和足够的附加数据，例如连接邀请的状态。你觉得这个设计怎么样？

此外，当性能至关重要时，是否有任何经过实战考验的方法在 MongoDB 中处理此类情况？我也对其他 dbs 建议持开放态度，我正在考虑 graph dbs。

【问题讨论】：

标签： mongodb neo4j nosql data-modeling graph-databases

【解决方案1】：

这个用例在 neo4j 这样的图形数据库中很容易处理。

例如，您可以使用 neo4j 的 Cypher 语言来存储用户 123 创建邀请并以这种方式将其发送给多个用户的事实：

MATCH (u:User {id: 123})
CREATE (u)-[:CREATED]->(i:Invitation {id: 999, text: '...', date: ..., location: ...})
UNWIND [234, 345, 456] AS inviteeId
MATCH (u1:User {id: inviteeId})
CREATE (i)-[:INVITED]->(u1)

每当用户响应时，您都可以这样存储它：

MATCH (u:User {id: 345}), (i:Invitation {id: 999})
CREATE (u)-[:RESPONDED {accept: false}]->(i)

最后，查看接受任何用户 123 邀请的不同用户：

MATCH (u:User {id: 123})-[:CREATED]->(:Invitation)<-[:RESPONDED {accept: true}]-(acceptor:User)
RETURN DISTINCT acceptor

【讨论】：