match多边类型查询优化实践

[undefined]

• nebula 版本：3.4.0
• 部署方式：单机
• 安装方式： tar.gz
• 是否上生产环境：Y
• 硬件信息
  • 磁盘（ 推荐使用 SSD）: 阿里云ESSD
  • CPU、内存信息：16核(vCPU) 128 GiB
• 问题的具体描述

查询任务需求：
根据之前的建议把业务标签作为Tag进行设计的MVP，导入样本数据集后想实现一个查询，把查询节点在业务边上流出的1～3层扩展与关联标签节点的路径给输出，但是过程执行时间需要50秒以上，想讨论一个比较明确的场景优化路径，提升现有查询效率；另：样本数据集目前占真实数据集0.1%，如果需要应用到真实数据集，得需要多少配置；

数据情况统计：

查询方式：

MATCH p=(v:biz_node)-[e:`biz_edge`*1..3]->(v2:biz_node)-[e1:`tag_edge`*1]->(v3:biz_tag_type) 
WHERE id(v) == "ID-jwhE5Y9CSJ1zCbiNMvTW4U1mxwgrvX" and id(v3) == "user_tag-1"
RETURN p
LIMIT 5;

执行时间消耗 53.348948 (s)

Profile语句情况：

服务器资源监控：

补充说明：
biz_node 之间为 id关联；biz_node与biz_tag_type为id关联；

[MuYi-方扬]

@undefined

根据之前的建议把业务标签作为Tag进行设计的MVP

根据之前的建议把业务标签作为Tag进行设计的MVP，这个你现在是怎么做的？

[undefined]

之前是外部数据源维护的，没法实现图查询

[yee]

查询中一定要用路径 p 吗？因为现在 nebula 中对路径 p 的实现比较重，这也是比较耗性能的地方。如果知道点边就可以，你可以试试下面的查询：

MATCH (v:biz_node)-[e:`biz_edge`*1..3]->(v2:biz_node), (v3:biz_tag_type)<-[e1:`tag_edge`*1]-(v2)
WHERE id(v) == "ID-jwhE5Y9CSJ1zCbiNMvTW4U1mxwgrvX" and id(v3) == "user_tag-1"
RETURN v,e,v2, e1, v3
LIMIT 5

[undefined]

不用p路径，执行时间消耗 54.085143 (s)，还有一个问题就是limit下推这么多版本还是没有走到存储层么

[undefined]

现在还存在资源没打上来，不了解为啥nebula查得慢时还不消耗资源的原因

[yee]

在 nebula-graphd.conf 修改一下 graph 如下的配置看看：

--max_job_size=12

估计是 graph 的并发执行没有利用上。limit 的优化这个涉及到执行模式的修改，像现在这种多步拓展是不能简单的直接将 limit 下推到存储层的。后面再考虑其他的优化方式

[undefined]

这个参数加上后，执行时间消耗 44.677033 (s)，但是我double size，执行时间并没有变化了

[undefined]

CPU有稍微有点变化了

[undefined]

我把v->v2->v3 拆分成您建议的v->v2, v3<-v2之后，执行时间消耗来到了 39.861758 (s)；

[yee]

如果数据中没有悬挂边的话，可以在 nebula-graphd.conf 中再加上下面的配置：

--optimize_appendvertices=true

然后再看看 profile 的结果

[undefined]

这个参数增加后，执行时间没有变化，还是39s.

[yee]

好，多谢反馈。

想再问一下，上述查询中写了 LIMIT，这个限制是表示业务中只要随便 5 条路径就可以吗？还是因为性能的原因才加的这个约束？之前提了 issue，想再进一步了解看看怎么在 nebula 中做些优化。

[undefined]

之前性能考虑，也担心样本的数据可能偏离一般情况太多导致结果集很大，但是如果limit仅在计算最后才处理，好像加不加也没啥关系

[yee]

好的，多谢，目前的 limit 的作用是这样的。