NebulaGraph 版本 v3.1.0 查询响应慢答案

【问题标题】：Slow query response with NebulaGraph version v3.1.0NebulaGraph 版本 v3.1.0 查询响应慢
【发布时间】：2022-11-30 10:35:45
【问题描述】：

星云图版本：v3.1.0 图示：1（128GM，2 TB SSD）元数据：1（128GM，2 TB SSD）存储：3（128GM，2TB SSD）

以下查询耗时约 20 分钟

匹配 (s:Student)-[r]-(a:CourseTcode)-[rr]-(b) 其中 a.CourseTcode.id == 522687 RETURN s, r, a, rr, b 限制 3 下面是简介 id 名称依赖分析数据 18 Project 16 ver: 0, rows: 3, execTime: 18355us, totalTime: 18365us 16 限制 14 ver：0，行：3，execTime：25528291us，totalTime：25528300us 14 过滤器 6 版本：0，行：11636144，execTime：8150513us，totalTime：8150522us

我像下面这样更改了我的查询，改进不大但还不够

匹配 (s:Student)-[r]-(a:CourseTcode)-[rr]-(b) 其中 id(a) == "522687" 返回 p, r, a, rr, b 极限 3 下面是简介 id 名称依赖分析数据 18 投影 16 版本：0，行：3，execTime：25216us，totalTime：25227us 16 限制 14 版本：0，行：3，执行时间：20186664us，总时间：20186672us 14 过滤器 7 版本：0，行：11636144，execTime：5799073us，totalTime：5799088us

【问题讨论】：

标签： nebula-graph

【解决方案1】：

关于配置文件，拥有完整的配置文件输出将有助于查看整个时间消耗分布。

1.正如您从 profile/explain 输出中看到的那样，查询首先开始寻找 a，因为它是目前唯一一个过滤条件的查询，正如您测试的那样，id(a) == "522687" 应该更快，但它应该很少有帮助，因为它没有完全是主要的缓慢阶段，同时，请尽可能使用 id(foo) == xxx 超过财产条件。

2.由于查询/存储分离设计的性质，当某些过滤器/限制无法下推到存储端时，将大量数据从存储中提取到查询引擎的成本很高。

2.1 在nebula graph这边，引入更多的优化规则和storage pushdown operators会有所帮助（progress: https://github.com/vesoft-inc/nebula/issues/2533 ），在这里我可以看到Filter/Limit确实很昂贵，也许还有一些空间需要优化。

2.2 在查询组合方面，添加更多信息以减少遍历的数据将有助于：

2.2.1 MATCH (s:Student)-[r:EdgeTypeA|:EdgeTypeB|:EdgeTypeC]-(a:CourseTcode)-[rr:EdgeTypeE|:EdgeTypeF|:EdgeTypeG]-(b)如果edges类型不是全部，请尽量注明，b的类型也一样。

2.2.2 另一种方法可能是限制中间的遍历，而不仅仅是最后阶段：

一世。它可能是这样的，如果你检查它的计划，限制将应用于遍历的第一部分

match (s:player)-[r]-(a:player)
where a.player.name == "Tim Duncan" 
with s,r,a limit 100
match (a:player)-[rr]-(b)
return s,r,a,rr,b limit 3

二.或者，更进一步，我们使用GO/ FETCH/ LOOKUP 来进行这个等价查询（一步一步查询，每一步限制）以实现更好的优化性能，强烈建议在巨大的情况下使用尽可能查询数据量。

2.3 从超级节点的角度来看，当很少的顶点可以连接到大量的顶点时，如果所有的查询都针对 sample(limit/topN) 数据而不是获取所有这些数据，或者对于那些超级节点，我们希望截断数据，可以配置storageDmax_edge_returned_per_vertex中的配置，即1000，或其他值。

【讨论】：