稠密点match 使用limit响应时间比较慢的问题

[DJSKL]

nebula 版本：2.6.1
部署方式：单机
安装方式：RPM
是否为线上版本：Y
硬件信息：SSD
问题描述：有索引的情况下 查询语句为MATCH (n:tag{})-[r]-(m) where n.name==‘XXX’ return * limit 100 稀疏点响应时间为0.035s，稠密点为17.3s。是否limit操作是全量的查询然后再截取部分数据返回？如何优化能缩短查询时间？

[wey]

麻烦帮忙打印 profile 加上您的 query看看哈，看看是没 limit 下推还是就是纯超级点慢，后者的话，考虑在storaged 的conf 里加上 max_edge_returned_per_vertex 配置一个适合的值，会有改善。

[DJSKL]

是这样的结果吗？

[DJSKL]

在storaged加了 max_edge_returned_per_vertex =1000的配置后查询时间由17s缩短到2s，还有别的优化的方法吗？理想时间是在1s以内

[wey]

用 lookup 试试呢，它的limit 下推确定是有的

[liaochunlin]

@wey

max_edge_returned_per_vertex

是nebula-graph2.6.1/etc/nebula-storaged.conf中加–max_edge_returned_per_vertex=1000吗？

[DJSKL]

是的

[liaochunlin]

– 这个要加吗？

[wey]

是的，这么加了之后扫描出边会丢弃超过这个数字的，对超级节点有采样的效果

[wey]

可以仿造这个例子谢谢看哈？

LOOKUP ON player where player.name == "Tim Duncan" | LIMIT 1 | GO FROM $-.VertexID over * BIDIRECT YIELD properties($^).name AS src_name, properties($$).name AS dest_name, src(edge) as s, dst(edge) as d , properties(edge) | LIMIT 5
+-------------+---------------------+-------------+-------------+------------------+
| src_name    | dest_name           | s           | d           | properties(EDGE) |
+-------------+---------------------+-------------+-------------+------------------+
| "player100" | "Tony Parker"       | "player101" | "player100" | {degree: 95}     |
| "player100" | "LaMarcus Aldridge" | "player102" | "player100" | {degree: 75}     |
| "player100" | "Marco Belinelli"   | "player104" | "player100" | {degree: 55}     |
| "player100" | "Danny Green"       | "player105" | "player100" | {degree: 70}     |
| "player100" | "Aron Baynes"       | "player107" | "player100" | {degree: 80}     |
+-------------+---------------------+-------------+-------------+------------------+
Got 5 rows (time spent 17872/28387 us)

Thu, 18 Nov 2021 09:29:53 UTC

[DJSKL]

感谢大佬语法改写，但是lookup和match的时间基本相同，都是2s左右

[wey]

如微信聊到，加上lookup的 limit 之后剪枝下推了，时间缩短到1s了哈，另外可以再考虑结合 sample

https://docs.nebula-graph.io/2.6.1/3.ngql-guide/8.clauses-and-options/sample/

[kyle]

@DJSKL

是否limit操作是全量的查询然后再截取部分数据返回？

现在确实是这样的，我们应该会在近期优化 limit 下推，关注一下后续版本更新

[kyle]

@wey

可以仿造这个例子谢谢看哈？

LOOKUP ON player where player.name == "Tim Duncan" | LIMIT 1 | GO FROM $-.VertexID over * BIDIRECT YIELD properties($^).name AS src_name, properties($).name AS dest_name, src(edge) as s, dst(edge) as d , properties(edge) | LIMIT 5
+-------------+---------------------+-------------+-------------+------------------+
| src_name    | dest_name           | s           | d           | properties(EDGE) |
+-------------+---------------------+-------------+-------------+------------------+
| "player100" | "Tony Parker"       | "player101" | "player100" | {degree: 95}     |
| "player100" | "LaMarcus Aldridge" | "player102" | "player100" | {degree: 75}     |
| "player100" | "Marco Belinelli"   | "player104" | "player100" | {degree: 55}     |
| "player100" | "Danny Green"       | "player105" | "player100" | {degree: 70}     |
| "player100" | "Aron Baynes"       | "player107" | "player100" | {degree: 80}     |
+-------------+---------------------+-------------+-------------+------------------+
Got 5 rows (time spent 17872/28387 us)

Thu, 18 Nov 2021 09:29:53 UTC

这个没用的，上层的 limit 被 InnerJoin 阻塞并没有被下推，所以还是计算全部之后 limit 的。

[wey]

奥奥，这样呀，原来 limit 还是会受整体的影响。
不过这个 case 下 @DJSKL 微信里反馈我中间 lookup 的limit 又缩短到了 1s ，应该怎么理解呢？

[kyle]

@DJSKL

在storaged加了 max_edge_returned_per_vertex =1000的配置后查询时间由17s缩短到2s，还有别的优化的方法吗？理想时间是在1s以内

这个配置项有可能导致查询结果错误，尤其是多步拓展，需要关注一下。
如果最终结果等于 limit 数，结果是正确的。如果小于，结果可能是错误的，原因是在拓展截断过程中满足 查询条件的点有可能未被采样。

[kyle]

@wey

lookup 的limit 又缩短到了 1s ，应该怎么理解呢？

这个可能是 lookup 和 match 实现差异，match 语句还有比较大的性能优化空间

[DJSKL]

好的

[DJSKL]

这个验证了下，基本缩短的1s是我采用了更小范围TAG的结果…在相同TAG范围lookup和match时间是一样的