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

问答 问题
,
1

我测试查询时间时，请问下多跳的查询当级数增多时数据库会崩溃，
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跳时间长了就报错
报错如下：

image
image1099×204 8.42 KB

[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
5

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

6

dmesg看一下，可能是oom了吧

8

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

9

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

10

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

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

2 个赞
11

可以使用 GO 加 COUNT

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

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

13

你要通过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 个赞