根据终点类型查询多跳关系

[wzxstc]

• nebula 版本：v3.2.1
• 部署方式：分布式
• 安装方式：RPM
• 是否为线上版本：Y
• 硬件信息
  • 磁盘（ 推荐使用 SSD）
  • CPU、内存信息
• 问题的具体描述
  
  关系如图所示，已知点A的id和目标点C的tag，想查询出符合条件的两跳或三跳的路径，我写的gqls：

MATCH p=(v)-[e:关系1|关系2*3]-(v2:C) where id(v)== “VID” RETURN DISTINCT p limit 100;

路径上的关系1或者2可能数量上千万，也存在稠密点，就设置了max_edge_returned_per_vertex= 1000，两跳的时候查询时间一分钟左右，三跳的时候基本查不出来了，有什么好的优化办法吗？感谢

[wzxstc]

有没有大佬帮助一下，谢谢了

[jmq2020]

查不出来 是因为 OOM 了还是 时间太久了

[wzxstc]

观察到内存占用很大，达到几十G，但还没有OOM，主要是时间太久，我把超时时间调到十分钟也没查出来

[jmq2020]

可以 profile 一下 看看 瓶颈在哪一个算子里

[wzxstc]

最耗时间的是这两步，语句是MATCH p=(v)-[e:involveTo|belongTo|likeTo*2]-(v2:组织) where id(v)== “事件_skynet事件_13” RETURN DISTINCT p limit 100; 这是查了两步的，三步就会超时了

[jmq2020]

1 做一下 compaction， 运行命令 SUBMIT JOB COMPACT;
2、在nebula-graph.conf 配置文件中 添加 max_job_size， 可以设置为 服务器核心数目 乘以0.5 到0.7 之间 的数字，增加并行度

[wzxstc]

已经做了compaction，max_job_size也增加之后查询速度确实快了不少，但瓶颈还是存在。随着查询条件里的关系增多，几十G的内存几乎被拉满影响了速度，又查不出来了。感觉单纯增加硬件资源并不能从根本上解决问题，或者有什么从设计上的解决方案么？

[lzy]

你可以用GO试试，内存占用应该会好点