问题描述
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核模式相差只有几个百分点。