match查询涉及到多个节点和边时,match后紧跟着的v的结果过多时导致查询很慢

  • nebula 版本:2.0.0beta
  • 部署方式(分布式 / 单机 / Docker / DBaaS):docker
  • 硬件信息
    • 磁盘( 必须为 SSD ,不支持 HDD)500GB SSD
    • CPU、内存信息:40C128G
  • 问题的具体描述
    已知对于节点wp,满足 name='pd’的节点个数<10,满足name='ccc’的节点个数>1000,当执行以下语句时:
match (v1:wp {name: 'pd'}) <-[e:wpc]- (v2:wp{name: 'ccc'}) return v1,v2

结果返回时间<0.01s
当执行以下语句时:

match (v2:wp{name: 'ccc'}) -[e:wpc]->  (v1:wp {name: 'pd'})  return v1,v2

结果返回时间>10s

猜测是match查询每次都是从紧跟着match的节点开始进行查询。能否在match查询中手动指定查询的起始节点是v1还是v2?

如果只涉及2个节点,那么对调v1,v2的位置可以解决上述问题,但是涉及到3个或更多节点和边时,就不太好解决了

match (v2:wp{name: 'ccc'}) -[e1:wpc]->  (v1:wp {name: 'pd'}) -[e2:wpc]->  (v3:wp {name: 'aaaa333'})  return v1,v2,v3

请问,上述问题有没有解决办法?

mark,慢的有点不正常

profile看一下呢

这个case要优化起点得等cbo优化器了

1赞

@tom-chensf 可以构造一点数据模拟一下类似的测试场景加入到我们的 CI 中

有大点,同一个索引可以查找出多条数据。

@zealot-shin 能否再帮我们查看一下两句查询 PROFILE 的执行计划?

使用 ldbc 数据复现场景

firstName 数量:
John 254
Yang 150
Abbas 1

CREATE TAG INDEX firstName ON person(firstName(20));
REBUILD TAG INDEX firstName;

# Q1 time spent 29041/38225 us
match (v1:person {firstName: "Abbas"}) <- [e:knows] - (v2:person{firstName: "John"}) return v1,v2

# Q2 time spent 895244/901047 us
match (v1:person {firstName: "John"}) - [e:knows] -> (v2:person{firstName: "Abbas"}) return v1,v2

profile 见附件
profile_1.log (52.7 KB) profile_2.log (51.9 KB)

1赞

插眼

match现在没有cbo优化机制,选择查询起点是从pattern从左到右,谁先匹配到就是谁,
q1 v1的数据量小所以后续查询到的中间数据量也比较小,q2相反;
用户可以根据自己的数据情况,用小数据量的点放前面,减少查询数据量

浙ICP备20010487号