关于多跳查询的一个测试,会将数据库跑崩溃

我测试查询时间时,请问下多跳的查询当级数增多时数据库会崩溃,
match (v:v_applyer)-[r:r_relation5]->() return count()

match (v:v_applyer)-[r:r_relation2]->() return count() 查得8000 耗时0.3s
match (v:v_applyer)-[r:r_relation3]->() return count() 查得70000 耗时4.2s
match (v:v_applyer)-[r:r_relation4]->() return count() 查得600000 耗时48s
到5跳时间长了就报错
报错如下:


[ERROR] Failed to reconnect, Failed to open transport, error: dial tcp 127.0.0.1:9669: connect: connection refused

用命令检查nebula状态:
[INFO] nebla-graphd: Exited

  • nebula 版本:2.0.0
  • 部署方式(分布式)3节点
  • 3 * linux64bit/CentOS/32核/CPU2.0GHz/RAM128GB 虚拟机 HDD

同样的节点和边数,在neo4j测下来 2跳 30ms 5跳 4s 所以5跳查询结果是500万,neo4j是可以查询出来的,

dmesg看一下,可能是oom了吧

是内存爆了,但是相比neo4j查询的速度慢好几个量级,nebula的5度查询汇总还查不出来

请问是不是查询语句效率不高,如果用 go step 的方式如何查呢?

目前的 MATCH 比 neo4j 慢是可以预见的。你部署的 neo4j 是单机版本吧。nebula graph 在分布式通信上的开销就不占优势。

5 跳会 OOM 这个跟现在的 MATCH 实现有关,现在 match 会获取顶点的所有属性,内存会占用大一些。今年上半年,我们会重点优化内存占用这块。而且保证性能会越来越快。

2 个赞

可以使用 GO 加 COUNT

GO 4 STEPS FROM "aplayer" OVER relation | YIELD COUNT(*)

可否不限制节点的id比如下面的:
GO 4 STEPS FROM * OVER relation | YIELD COUNT(*)
查出所有4跳的关系链

你要通过go拿整个路径情况,go不是专门用于这样的场景的。
GO 4 STEPS FROM * OVER relation 是拿第四跳的数据,前三条的数据是不会给用户返回的,假如你要读第四跳的数据,直接这样

GO 4 STEPS FROM * OVER relation YIELD relation._src, relation._dst

假如你想或者四跳之内所有数据,那么你可以用 GO 1 TO 4 STEPS 这样会把每一跳的点都拿到,但是不会由四跳的全路径,你要用全路径,还是用match比较合适

1 个赞

浙ICP备20010487号