Database design 将n个节点连接到单个节点的最佳方法？

我正在为我目前正在构建的应用程序建模一个图形，其中我有n个用户连接到n个用户，我还有n个帖子，这些帖子可以被n个用户所喜欢。因此，对于给定的用户，结构看起来是这样的，

如果用户喜欢100个Post节点，它将为节点生成100条边（关系），当Post为n时，边也将为n。 因此，一个用户将连接到n个用户、n个帖子和n个未来节点类型

使用一个中间节点，从而减少给定节点的边，看起来像这样

如果用户有一个名为Collection的中间节点，它将连接到likes，因为这是一个属性图，我可以向中间节点添加一个属性，并使其行为类似于来自用户的连接（likes.username=user.username）

这将类似于这个问题（）

我的想法是

这种中间连接节点的方式可以将垃圾从主节点中隔离出来，从而加快自定义算法的速度

我的问题,

解决这一问题的最佳方案是什么

为什么我要把这个解决方案考虑到另一个问题？

---

这种解决方案有优点也有缺点

主要的缺点是遍历操作的开销会更大，也就是说，在找到帖子之前，您必须再遍历一个节点

优点如下：

• 当您添加新的“like”时，用户节点上的争用更少，即User@version不会增加，因此您将能够并发地对用户进行更新，而不会出现版本冲突
• 向“喜欢”节点添加信息的能力。您也可以单独使用边执行此操作，但必须复制所有边上的信息
• 一个较小的用户，特别是在嵌入式/树形包的阈值之下，只考虑使用二进制协议，当你有一个树形包时，它不会被立即序列化到客户端，但是你会有一个迭代器，因此获取单个用户的开销将不是很重要。另一方面，使用HTTP协议，您将接收带有顶点的所有边缘RID，因此在这种情况下，使用第二种方法将节省大量带宽和计算时间

---

关于您的问题，最好的解决方案是更适合您的工作负载的解决方案：如果您对用户进行大量更新，第二个解决方案将立即为您带来好处；如果您经常单独获取用户，第二种解决方案也会带来好处；另一方面，如果您主要关心的是快速遍历，那么第二种解决方案将不是很合适。

根据学习Neo4j这本非常好的书（由Rik Van Bruggen提供），您的问题被称为“密集节点”或“超节点”：连接太多的节点

根据书中的说法，超级节点

“成为图遍历的一个真正问题，因为图 数据库管理系统必须评估所有连接的数据库 与该节点的关系，以确定下一步 将在图形遍历中进行。”

Rik提出的解决方案非常接近您的解决方案（添加一个中间节点）：它包括在用户和您喜欢的帖子之间添加一个“元”节点。这个元节点最多应该有100个连接。如果当前元节点达到100个连接，则必须创建一个新的元节点并将其添加到层次结构中，如图所示，显示了一个流行艺术家和粉丝的示例：

Neo4j团队一直在努力提高超级节点的性能，这可以从（例如）改变节点在磁盘上以链表结构存储的关系中看出

我相信最好的方法是在开始时让你的图形模型尽可能简单。您还没有密集节点问题，过早的优化可能会给您的模型增加一些不必要的复杂性。如果将来密集节点成为问题，您可以更准确地更改模型。简单一开始是个不错的选择

您可以在以下链接中了解更多关于图形数据库中超级节点的信息：