performance - Neo4j super 节点问题 - 扇出模式

标签 performance neo4j cypher graph-databases node-neo4j

我是图形数据库领域的新手,正在研究 Neo4j 并学习 Cypher,我们正在尝试对图形数据库进行建模,这是一个相当简单的模型,我们有用户,我们有电影,用户可以 查看 电影,价格 电影,创建播放列表和播放列表可以电影。

问题是关于 super 节点性能问题。我将从我目前正在阅读的一本非常好的书中引用一些内容 - Rik Van Bruggen 的《Learning Neo4j》,所以这里是:

A very interesting problem then occurs in datasets where some parts of the graph are all connected to the same node. This node, also referred to as a dense node or a supernode, becomes a real problem for graph traversals because the graph database management system will have to evaluate all of the connected relationships to that node in order to determine what the next step will be in the graph traversal.



书中提出的这个问题的解决方案是让一个Meta节点与它有100个连接,第101个连接要链接到一个新的Meta节点,该节点链接到以前的Meta节点。

DENSE_LIKES fanning out

我看到官方 Neo4j 博客上的一篇博文说他们将在不久的将来解决这个问题(博文来自 2013 年 1 月)- http://neo4j.com/blog/2013-whats-coming-next-in-neo4j/

更确切地说,他们说:

Another project we have planned around “bigger data” is to add some specific optimizations to handle traversals across densely-connected nodes, having very large numbers (millions) of relationships. (This problem is sometimes referred to as the “supernodes” problem.)



你对这个问题有什么看法?我们应该采用 Meta 节点扇出模式还是采用每个教程似乎都在使用的基本关系?还有其他建议吗?

最佳答案

更新 - 2020 年 10 月 . This article is the best source on this topic ,涵盖 super 节点的方方面面
(下面是我的原始答案)
这是个好问题。这不是一个真正的答案,但为什么我们不能在这里讨论这个?从技术上讲,我认为我应该将您的问题标记为“主要基于意见”,因为您明确征求意见,但我认为值得讨论。
无聊但诚实的答案是它始终取决于您的查询模式。如果不知道您将针对这种数据结构发出什么样的查询,就真的没有办法知道“最佳”方法。
super 节点也是其他领域的问题。图数据库有时在某些方面很难扩展,因为其中的数据很难分区。如果这是一个关系数据库,我们可以垂直或水平分区。在具有 super 节点的图形数据库中,一切都“接近”于其他一切。 (阿拉斯加农民喜欢 Lady Gaga,纽约银行家也喜欢)。不仅仅是图形遍历速度, super 节点对于各种可扩展性来说都是一个大问题。
Rik 的建议归结为鼓励您创建 super 节点的“子集群”或“分区”。对于某些查询模式,这可能是一个好主意,我并不是反对这个主意,但我认为隐藏在此处的是聚类策略的概念。您分配了多少个元节点?每个元节点有多少个最大链接?你是如何将这个用户分配给这个元节点(而不是其他一些)的?根据您的查询,这些问题将很难回答,很难正确实现,或两者兼而有之。
一种不同(但概念上非常相似)的方法是克隆 Lady Gaga 大约一千次,复制她的数据并使其在节点之间保持同步,然后在克隆之间断言一堆“相同”关系。这与“元”方法没有什么不同,但它的优势在于它将 Lady Gaga 的数据复制到克隆,并且“元”节点不仅仅是导航的愚蠢占位符。但是,大多数相同的问题都适用。
不过,这里有一个不同的建议:这里有一个大规模的多对多映射问题。如果这对您来说真的是一个非常大的问题,那么您最好将其分解为一个包含两列的单个关系表 (from_id, to_id) ,每个引用一个neo4j节点ID。然后,您可能拥有一个主要是图形的混合系统(但有一些异常(exception))。这里有很多权衡;当然,您根本无法在 cypher 中遍历该 rel,但它会更好地扩展和分区,并且查询特定 rel 可能会快得多。
这里有一个普遍的观察:无论我们是在谈论关系、图形、文档、K/V 数据库,还是其他任何东西——当数据库变得非常大,并且性能要求变得非常强烈时,人们几乎不可避免地会得到一些一种具有多种 DBMS 的混合解决方案。这是因为不可避免的现实,即所有数据库都擅长某些事情,而不擅长其他事情。因此,如果您需要一个最适合所有方面的系统,您将不得不使用不止一种数据库。 :)
在这些情况下,neo4j 可能可以做很多优化,但在我看来,系统需要一些关于访问模式的提示,以便在这方面做得很好。在现有的 2,000,000 个关系中,如何对端点进行最佳集群?旧关系是否比新关系更重要,反之亦然?

关于performance - Neo4j super 节点问题 - 扇出模式,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/27568265/

相关文章:

sql - mysql - 创建行与列性能

javascript - node.js 找不到 'neo4j' 模块 (Thingdom)

neo4j - 如何删除所有没有任何关系的节点 - neo4j/cypher

arrays - 如何用下一个最接近的数字替换数组中的 NaN?

javascript - 高性能 dom 添加和删除

iPhone动画效率解决方案、分层问题

neo4j - Neo4j Cypher中有多个不相关的查询?

neo4j - 我怎么能在neo4j中写这个查询?

elasticsearch - 图辅助搜索结果过滤示例

java - 从 Java 中的 Cypher 查询检索结果缓慢 - Neo4j 2.0