Neo4j超级节点问题 - 扇出模式

Question

我是Graph Database场景的新手，在研究Neo4j并学习Cypher时，我们正在尝试建模图形数据库，它是一个相当简单的数据库，我们得到了用户< / em>，我们有电影，用户可以查看 电影，价格 电影，创建播放列表和播放列表可以拥有 电影。

问题是关于超级节点性能问题。我将从我正在阅读的一本非常好的书中引用一些内容 - Rik Van Bruggen学习Neo4j ，所以这里是：

  

然后，在图表的某些部分的数据集中会出现一个非常有趣的问题   都连接到同一节点。此节点，也称为密集节点或   超级节点因图形数据库而成为图遍历的真正问题   管理系统必须评估所有连接关系   该节点，以确定图遍历中的下一步将是什么。

本书提出的这个问题的解决方案是让一个Meta节点与它有100个连接，第101个连接链接到一个链接到前一个元节点的新Meta节点。

我看过官方Neo4j博客的一篇博文，说他们将在未来解决这个问题（博客文章是从2013年1月开始） - http://neo4j.com/blog/2013-whats-coming-next-in-neo4j/

他们更确切地说：

  

我们围绕“更大数据”计划的另一个项目是添加一些特定的优化来处理密集连接节点上的遍历，这些节点具有非常大量（数百万）的关系。 （这个问题有时被称为“超级节点”问题。）

您对此问题有何看法？我们应该使用Meta节点扇出模式还是使用每个教程似乎都使用的基本关系？还有其他建议吗？

Answer 1

这是一个很好的问题。这不是一个真正的答案，但为什么我们不能在这里讨论这个问题呢？从技术上讲，我认为我应该将你的问题标记为“主要基于意见”，因为你明确征求意见，但我认为值得讨论。

无聊而诚实的答案是它总是取决于您的查询模式。如果不知道您将针对此数据结构发出什么类型的查询，则无法知道“最佳”方法。

超级节点也是其他领域的问题。图形数据库有时很难在某些方面进行扩展，因为它们中的数据难以分区。如果这是一个关系数据库，我们可以垂直或水平分区。在图表数据库中，当你有超级节点时，一切都“接近”其他一切。 （阿拉斯加的农民喜欢Lady Gaga，纽约的银行家也是如此）。除了图形遍历速度之外，超节点对于各种可扩展性来说都是一个大问题。

Rik的建议归结为鼓励您创建超级节点的“子集群”或“分区”。对于某些查询模式，这可能是一个好主意，我并不是在想这个想法，但我认为隐藏在这里的是聚类策略的概念。您分配了多少个元节点？每个元节点有多少个最大链接？你是如何将这个用户分配给这个元节点的（而不是其他节点）？根据您的疑问，这些问题很难回答，难以正确实施，或两者兼而有之。

另一种（但在概念上非常相似）的方法是克隆Lady Gaga大约一千次，并复制她的数据并使它们在节点之间保持同步，然后断言克隆之间的一堆“相同”关系。这与“元”方法没有什么不同，但它的优势在于它将Lady Gaga的数据复制到克隆中，而“Meta”节点不仅仅是导航的愚蠢占位符。但是大多数相同的问题都适用。

这里有一个不同的建议：这里有一个大规模的多对多映射问题。如果这对您来说是一个非常大的问题，那么最好将其分解为具有两列(from_id, to_id)的单个关系表，每个列引用一个neo4j节点ID。然后，您可能拥有一个主要是图形的混合系统（但有一些例外）。这里有很多权衡;当然你根本无法在cypher中遍历那个rel，但它会更好地扩展和分区，并且查询特定的rel可能要快得多。

这里有一个普遍的观察：我们是在谈论关系，图形，文档，K / V数据库还是其他什么 - 当数据库变得非常大，并且性能要求变得非常强烈时，人们几乎不可避免地会结束使用某种具有多种DBMS的混合解决方案。这是因为不可避免的现实，所有数据库都擅长某些事情，而不擅长其他数据库。因此，如果您需要一个最擅长一切的系统，那么您将不得不使用多种数据库。 ：）

在这些情况下，neo4j可能会做很多优化，但在我看来，系统需要对访问模式提供某些类型的提示才能做得非常好。在目前的2,000,000个关系中，如何使端点最佳集群？旧关系比新关系更重要，反之亦然？

Answer 2

重新。在Neo4j博客中，应该在Neo4j 2.1（及更高版本）中增强密集节点支持，另请参阅http://neo4j.com/blog/neo4j-2-1-graph-etl/

Answer 3

（免责声明：不是答案，而是一些讨论）

2013年neo4j博客文章中提到了这个github commit的链接，其中讨论了预期的问题范围及其解决方案。总而言之，它没有解决一般supernode问题。相反，当在supernode具有的多种关系类型（和方向）中，某些类型（方向）恰好比其他类型（方向）具有不成比例的边缘时，它减轻了问题。引擎能够根据类型和方向进行过滤。

更通用的解决方案是来自Titan（https://stackoverflow.com/a/21385213/1311956）的vertex centric方法，它将边缘按一个或多个属性组合排序，从而产生O（log（E））搜索性能，其中E是supernode中的边/边数。

Neo4j具有关系索引的概念。与Titan的vertex centric方法不同，该指数是全球性的。但是，关系索引是Neo4j中的遗留索引。这在另一个stackoverflow thread中讨论。

Supernode的另一个问题是存储问题导致存储问题和IO成本。