请问order by和limit算子,是不是并没有下推到存储层计算?

例如,有这样一条语句:GO xxx | order by xxx | limit 5。通过阅读nebula graph源码,发现管道的前一句执行完毕,把结果传给下一句。这样的话,假如GO要发送到多个分区去执行查找,把各个分区的数据都拉回到本地后再做排序和截断吗?有没有做这样的优化:GO语句发送到每个分区时,带着order by和limit算子,先在每个分区做排序和截断,再拉回本地后,所有分区的数据再排序,再截断。这样网络中传输的数据量就会小,性能就会高。请问,nebula graph做了这样的优化吗?

你理解的是对的,目前没有做limit、order还没有做下推优化,暂时只有部分filter是下推了的。2.0之后会把这些部分都下推。

1 个赞

2.0后还会继续开源吗?

2.0 nebula 源码会开源的

1 个赞

请问现在进展如何了?试了下目前的版本似乎还不支持,通过PROFILE看到执行计划还是先从storage查出了所有的数据。

# 图空间中company大约70w数据,下面语句耗时超过10s
MATCH (v:company) RETURN v LIMIT 10

limit 优化下推目前还在开发阶段,尚未 ready 哈

我就说 性能不高呢 原来问题再这里啊
我这边有按照边的属性值 order desc 后取 top 100的需求 发现 要6秒 左右 边个数1万
版本 2.0.1 ssd

徐老师要不要单独开个帖子讨论下呀,毕竟这个帖子的所有人是 zhaohaifei 大兄弟

1 个赞

嘿嘿,在这里讨论也无妨。 :grin:

1 个赞

请问这个下推实现了吗?3.5.0版本,貌似还没有实现这个功能。我是从graphd节点用tcpdump抓包确认的。是先从storage节点返回了所有数据到graphd,然后graphd再order by 和 limit 返回给请求方。

看下及执行计划中有 limit 的话,就是下推了,么有的话,@muyi 来看看呢

语句:GO FROM 2805364572 OVER txl YIELD txl._src AS src, txl._dst AS dst, txl.weight as weight | order by $-.weight desc | limit 4

执行计划如附件

explain.csv (1.5 KB)

tcpdump抓包:
tcpdump_graph_to_storage.txt (196.1 KB)

我观察go的语法,我猜是因为这里要支持 vertex_list 作为输入,所以没法下推到存储层,必须要拉取所有vid的结果到计算层来才能做order by + limit?


一个可能的优化方案是,如果发现vertex_list长度=1,执行下推计算?

3.6版本里,go的话是有下推的。已经和 @zhaohaifei 说的是一样的。先发到各个分区,带着limit,然后返回到graphd,再做一次截断

我在3.6版本上测试了,类似下面的语句,正如你截图那样,的确有下推limit
GO FROM 10086 OVER xxxxx YIELD xxxxx.weight as weight | limit 4
但如果加上【边属性的order by】,【order by】和【limit】就没有下推了。题主和我的预期是这样的TopN场景,也可以做到下推。
GO FROM 10086 OVER xxxxx YIELD xxxxx.weight as weight | order by $-.weight desc | limit 4