用NebulaGraph版本v3.1.0进行缓慢的查询响应

Question

NebulaGraph版本: v3.1.0图形:1(128 TB，2 TB SSD)元存储器:1(128 TB，2 TB SSD)存储:3(128 TB，2 TB SSD)

下面的查询大约花了20分钟

匹配(s:学生)-r-(a:CourseTcode)-rr-(B)其中a.CourseTcode.id == 522687返回s，r，a，rr，b限制3是配置文件id名称依赖关系分析数据18 Project 16 ver: 0，行: 3，execTime: 18355 is，totalTime: 18365us 16限制14 ver: 0，行: 3，execTime: 25528291 is，totalTime: 25528300us 14 Filter 6 ver: 0，行: 11636144，execTime: 8150513us，totalTime: 8150522 is。

我修改了我的查询，如下所示，虽然没有什么改进，但还不够

匹配(s:学生)-r -(a:CourseTcode)-rr-(b)其中id(a) == "522687“返回p，r，a，rr，b限制3是配置文件id名称依赖关系分析数据18投影16 ver: 0，行: 3，execTime: 25216 is，totalTime: 25227us 16限制14ver: 0，行: execTime: 20186664us，totalTime: 20186672us14筛选器7 ver: 0，行: 11636144，execTime: 5799073 is，totalTime: 5799088 is。

Answer 1

对于配置文件，让完整的配置文件输出来查看整个时间消耗分布将是很有帮助的。

1.从配置文件/解释输出中可以看到，查询首先开始寻找，因为它是目前唯一过滤了条件的查询，正如您测试的那样，id(a) == "522687"应该更快，但是它应该很少起作用，因为它根本不是主要的慢阶段，同时，请尽可能地对属性条件使用id(foo) == xxx。

2.由于查询/存储分离设计的性质，当一些过滤器/限制不能向下推到存储端时，将大量数据从存储端获取到查询引擎将是非常昂贵的。

2.1在星云图方面，引入更多的优化规则和存储下推操作符将有帮助(进度：https://github.com/vesoft-inc/nebula/issues/2533 )，在这里我可以看到过滤器/限制是非常昂贵的，也许还有一些需要优化的空间。

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

2.2.1 MATCH (s:Student)-[r:EdgeTypeA|:EdgeTypeB|:EdgeTypeC]-(a:CourseTcode)-[rr:EdgeTypeE|:EdgeTypeF|:EdgeTypeG]-(b)如果边缘类型不是所有的，请尽可能指定它，同样适用于b类型。

2.2.2另一种办法可以是在中间阶段限制导线，而不仅仅是在最后阶段：

i.可能是这样的，如果您检查它的计划，这个限制将在遍历的第一部分中应用。

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在超级节点方面，当很少的顶点可以连接到大量的顶点时，如果所有查询的目标都是样本(极限/topN)数据而不是全部，或者，对于这些超级节点，我们希望截断数据，可以配置storageD max_edge_returned_per_vertex中的配置，即1000或其他值。