使用MATCH语句使用TAG中的属性和属性的CONTAINS进行模糊匹配,效率极其的慢,

nebula 版本:2.0.1
部署方式(单机)
是否为线上版本:Y
硬件信息
磁盘SSD
CPU、内存信息
CPU 16核 内存 60GB
问题的具体描述
相关的 meta / storage / graph info 日志信息(尽量使用文本形式方便检索)
meta和graph使用的是默认的配置,storage使用的是配置文件下的storage.production
节点数量为4亿左右,边4.4亿
问题一、
类似查询语句:MATCH(n:person{name:‘王浩’})-[:per_invest_ent]->(e:enterprise) where e.name CONTAINS ‘小米科技有限责任公司’ RETURN n
查询效率极其低下,120S左右才返回数据,查询其他的参数,有一些查询直接宕机,GO的语法中需要使用vid,LOOKUP 不支持 CONTAINS,从使用方面来说,有哪些方法,通过改语句也好,还是什么办法,可以提升一下查询的效率吗?
问题二、
看到论坛里面的回复,MATCH语句是通过全部扫描所有的数据以后再进行过滤条件筛选的吗?

帮忙profile 一下,看看

OOM了。稍等一下



这是第二次的结果,第一次就Network err 了

看这个 profile 差不多花了不到 10s 啊,和 120s 语句不一样吗?看执行计划的话,开销主要在 Project 的PathBuild 表达式 和 GetVertices 上,这两个都是我们目前已知的。

应该是第二次查询有相应的缓存机制,第一次查询时间会比较长,我再贴一个没查过的



这个是以这个相同配置搭建了一个双节点的集群后,查出来了

这里性能确实是个问题,我们之后的版本会做针对性的优化。

不会的。执行计划上看命中了 Prefix 类型索引,只会扫 name:'王刚' 的数据作为起点,起点扫出来有 6 万多行,数据量还是比较大的。

这个在扫描name:'王刚’之后,会将王刚所关联的enterprise一并加入到缓存中吗,因为第二次查询时间会明显下降,这个缓存是一直存在于内存中,还是保留一段时间后就释放内存呢

rocksDB 会 cache 一部分之前访问过的数据,rocksDB block cache 的大小可以在 nebula-storage.conf 中通过配置项 rocksdb_block_cache 来配置。block cache 中缓存的数据是一直在内存的。

1 个赞

OKOK,感谢,就是想问的这个问题

浙ICP备20010487号