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

用户问答 使用问题
#1
  • 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

请问，上述问题有没有解决办法？

#2

mark，慢的有点不正常

#3

profile看一下呢

#4

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

1赞
#5

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

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

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

#6

使用 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赞
#7

插眼

#8

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

浙ICP备20010487号