max_edge_returned_per_vertex配合where的问题

版本1.1.0

官方文档中说到

如果已设置 max_edge_returned_per_vertex=10,使用 WHERE 进行过滤时,实际边数量大于 10,此时返回 10 条边,还是所有边?

Nebula Graph 先进行 WHERE 条件过滤,如果实际边数量少于 10, 则返回实际边数量。反之,则根据 max_edge_returned_per_vertex 限制返回 10 条边。

我遇到一个情况如下
(前提是我设置了max_edge_returned_per_vertex=1w)有一个点发散出去3w条边,
但是这3w条边是有多个rank值的,假如rank值是1、2、3、4、5
我写一个ngql

go from hash('xxx') over someedge

此时获取到1w条边,这是没问题的。
但是我写如下的sql

go from hash('xxx') over someedge where someedge._rank=4

此时返回是空的(后来我将max_edge_returned_per_vertex增大后可以正常返回),就仿佛判断完前1w个之后就不管后面了,这样的表现对吗?~

期望表现如官方文档所述,先where完之后,再对where的结果进行max_edge_returned_per_vertex限制

1 个赞

这个应该是不支持动态改的,直接在配置文件改然后重启服务试试。配置文件默认在 /usr/local/nebula/etc/ 目录下。

支持哒~~

max_edge_returned_per_vertex	2147483647	每个稠密点,最多返回多少条边,多余的边截断不返回	UPDATE CONFIGS 命令修改,立刻生效

要熟记自家文档呀 哈哈

max_edge_returned_per_vertex这个参数设置的是最多从storage捞多少数据. 从storage取到数据之后才会送给graph做过滤, 所以有可能出现你这种情况. 如果你内存足够的话, 你可以把max_edge_returned_per_vertex这个参数设置的大一点, 然后用limit限制最终返回的数据条数

1 个赞

麻烦问下这个后续有计划升级改造一下嘛?
而且这个和文档上的说明也不太一致,文档特意强调了是先where再截断,按您所述,现在是先截断的,然后才去过滤,看看是否需要更新下文档~ 这个给我弄得挺迷惑…以为灌数的时候灌丢了…

另外 以您的经验来看 max_edge_returned_per_vertex 一般设置多少较为合适呢?

这个我反馈下相关开发人员, max_edge_returned_per_vertex这个参数一般你用默认值就好, 默认值是2147483647

你实际执行的sql的where是啥? 我看了下代码, 如果where语句的filter可以下推给storage的话, 那确实是先filter再截断, 如果filter无法下推的话, 就是我之前说的那样先截断, 获取到数据后送给graph再去filter. 所以需要看下你实际sql的filter能不能下推

我的实际执行语句就是上述提到的那句

go from hash('xxx') over someEdge BIDIRECT where someEdge._rank==4 yield someEdge._dst, someEdge._rank

这个感觉看起来感觉应该能下推似的~
但是实际上确实受到截断的影响了

现在filter下推只有在正向边的时候,你的查询是双向,所以没有下推

3 个赞

我去~~ 这么细节的~~! 好吧 多谢啦

@CPWstatic 2.0这个地方要不要改下,主要问题在于filter只能作用于一个edge type,只要接口里面可以按edge type传filter 就不会有任何问题。tag也一样,单独传filter。另外不支持下推跨任意类型的filter。这样是不是就可以了?

2 个赞

现在支持反向边的filter下推吗?