如何解决neo4j 中的图回归检测
75 millions of nodes
238 millions of relationships
好几年了。
我定期从外部数据中重新生成它(通过导入 csv)。
然后我进行批量allshortestpaths搜索,单次搜索需要几毫秒。但整批 10 万次搜索通常需要 5-10 分钟。
前一段时间批量搜索变得慢了好几倍 - 总是 30++ 分钟。
是否有任何工具可以调查此问题?我使用cypher和java驱动,当时没有neo4j更新(现在是4.0.11)
我尝试使用 Oracle linux 而不是 Debian 和 neo4j 4.2.4 而不是 4.0.11 的更强大的服务器,但这没有帮助。所以,问题可能出在图表内部。
我已经为慢速搜索设置了日志记录,但没有比几十毫秒慢的搜索。不幸的是,我无法恢复到旧的(更快的)图表来测量平均时间。
更新:
旧搜索
MATCH (one:Obj{oid:'id1'}) with one MATCH (two:Obj{oid:'anyOf100kId'}),path=allshortestPaths((one) -[*0..4]-(two)) WHERE ALL (x IN RELATIONSHIPS(path) WHERE x.val<130) return path limit 100;
+----------------------------------------------------------------------------------------------------------+
| Plan | Statement | Version | Planner | Runtime | Time | DbHits | Rows | Memory (Bytes) |
+----------------------------------------------------------------------------------------------------------+
| "PROFILE" | "READ_ONLY" | "CYPHER 4.2" | "COST" | "INTERPRETED" | 44 | 82495 | 7 | 7707104 |
+----------------------------------------------------------------------------------------------------------+
+----------------------------+-------------------------------------------------------------------------------------------------+----------------+------+---------+----------------+------------------------+
| Operator | Details | Estimated Rows | Rows | DB Hits | Memory (Bytes) | Page Cache Hits/Misses |
+----------------------------+-------------------------------------------------------------------------------------------------+----------------+------+---------+----------------+------------------------+
| +ProduceResults@graph.db | path | 1 | 7 | 224 | | 0/0 |
| | +-------------------------------------------------------------------------------------------------+----------------+------+---------+----------------+------------------------+
| +Limit@graph.db | 100 | 1 | 7 | 0 | | 0/0 |
| | +-------------------------------------------------------------------------------------------------+----------------+------+---------+----------------+------------------------+
| +ShortestPath@graph.db | path = (one)-[anon_112*0..4]-(two) WHERE all(x IN RELATIONSHIPS(path) WHERE x.val < $autoint_2) | 1 | 7 | 82267 | 7707104 | 0/0 |
| | +-------------------------------------------------------------------------------------------------+----------------+------+---------+----------------+------------------------+
| +CartesianProduct@graph.db | | 1 | 1 | 0 | | 0/0 |
| |\ +-------------------------------------------------------------------------------------------------+----------------+------+---------+----------------+------------------------+
| | +NodeIndexSeek@graph.db | two:Obj(oid) WHERE oid = $autostring_1 | 1 | 1 | 2 | | 0/0 |
| | +-------------------------------------------------------------------------------------------------+----------------+------+---------+----------------+------------------------+
| +NodeIndexSeek@graph.db | one:Obj(oid) WHERE oid = $autostring_0 | 1 | 1 | 2 | | 0/0 |
+----------------------------+-------------------------------------------------------------------------------------------------+----------------+------+---------+----------------+------------------------+
7 rows available after 0 ms,consumed after another 44 ms
现在我已经切换到参数 + UNWIND,但看不出有什么区别。
在java List中我放了100k ids,然后
final String qu = "MATCH (one:Obj {oid: 'id1' }) WITH one UNWIND $batch AS row MATCH (two:Obj {oid:row}),path=allshortestPaths((one) -[*0..4]-(two)) WHERE ALL (x IN RELATIONSHIPS(path) WHERE x.val<130) return path limit 10000";
Result r = session.run(qu,parameters("batch",orgs));
即使在 30 分钟后搜索也没有停止。单独搜索也更好,因为我可以打破循环并至少处理部分结果。
那么,有什么想法吗? 1 个月前,它的运行速度要快得多。
解决方法
不是真正的答案:我没有找到/创建一个工具来检测大型节点集群。通过添加更多 RAM 以容纳所有 64GB 数据,问题得到解决。
此外,还花了几天时间试图进一步提高性能,但失败了。 不同的 JVM 设置几乎没有任何作用(大堆、大页面缓存)。 社区版好像硬限制在10核,但有效限制甚至更低,因为4核和10-20核模式相差只有几个百分点。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。