【问题标题】:Poor performance of Neo4j Cypher query for transitive closure传递闭包的 Neo4j Cypher 查询性能不佳
【发布时间】:2016-02-07 00:43:57
【问题描述】:

我有一个包含约 89K 节点和约 120 万关系的图,并试图通过以下 Cypher 查询获得单个节点的传递闭包:

start n=NODE(<id of a single node of interest>)
match (n)-[*1..]->(m)
where has(m.name)
return distinct m.name

不幸的是,这个查询消失了,似乎没有回来(尽管公平地说,此时我只给了它大约一个小时的执行时间)。

关于如何优化我在这里得到的东西的任何建议,或者更好的方法来满足要求?

注意事项:

  • Neo4J v2.0.0(通过 Homebrew 安装)。
  • Mac OSX 10.8.5
  • Oracle Java 1.7.0_51
  • 8GB 物理 RAM(neo4j JVM 分配任何默认值)
  • 数据库托管在 SSD 卷上。
  • 查询是通过管理 Web UI 的“数据浏览器”提交的。
  • “名称”是一个自动索引字段。
  • CPU 使用率相当低 - 平均约为 8 个内核的 20%。
  • 我还没有开始分析 Neo4J 服务器 - 我第一次尝试锁定了 VisualVM。

【问题讨论】:

  • 你的图中有循环吗?

标签: neo4j cypher


【解决方案1】:

这可能是路径的组合爆炸,想试试这个吗?

start n=NODE(<id of a single node of interest>),m=node:node_auto_index("name:*")
match shortestPath((n)-[*]->(m))
return m.name

如果没有最短路径,它看起来像那样,但由于您只对来自n 的可访问节点感兴趣,所以上面应该足够好。

start n=NODE(<id of a single node of interest>),m=node:node_auto_index("name:*")
match (n)-[*]->(m)
return distnct m.name

【讨论】:

  • 谢谢迈克尔 - 工作。查询运行大约需要 10 分钟(产生约 3.2K 的结果),但这仍然比我的原始查询有了很大的改进。
【解决方案2】:

尝试查询 - https://code.google.com/p/gueryframework/ - 这是一个独立的库,但有一个 neo4j 适配器。即,您将不得不以查询格式重写您的查询。

更好地支持传递闭包是开发查询的主要原因之一,我们主要在需要可达性/模式分析的软件分析工具中使用它(例如,http://xplrarc.massey.ac.nz/ 中的反模式查询是使用查询计算的)。

neo4j google 群里有一个简短的讨论: https://groups.google.com/forum/#!searchin/neo4j/jens/neo4j/n69ksEJxDtQ/29DNKyWKur4J

还有一个(旧的,未维护的)项目,带有一些基准测试代码:

https://code.google.com/p/graph-query-benchmarks/

干杯,詹斯

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多