match语句在查询边深度导致占用内存剧增

场景:目前库中有7千万数据,单节点32G内存,需要查询两个选定的人员之间是否存在关系
语句:match p=(v1:ry)-[e*6]-(v2:ry) where id(v)==“vid1” and id(v2)==“vid2” return p limit 3
有很多人员是稠密点,稠密点的边配置数据是500(因此还导致数据统计的值不准确);
当边的数量为4时,内存基本吃满,但是还能查出数据,当边的数量为6,内存根本不够,直接报错。
目前match语句的查询和go很像,都是从左边往右边去寻边,每条组合都会生成并存在内存,那么查询的边的深度一旦增大,内存的占用将指数型上升,数据总量才4G,却在查询中使用了接近30G的内存,查出的数据还不全。感觉还是需要优化查询的算法,和内存管理。
考虑将多层查询对半拆成两个match语句,但是没有找到nebula3.0在同一个query中对多match语句的支持,网络上资料太少,所以进来问一下。
目前我若是放开稠密点的设置,并且将边的深度增加到8或10,那么即使使用集群式多台大内存服务器也支撑不了查询。所以希望能找到合适的解决方法。
至于go语句,go的寻址路径是walk类型,不适合目前的需求。
求个大佬给个解决方案,还有目前nebula库的数据量并不是很大,随着使用时间的增长,数据量还会进步增加。

3.0 是支持多 match 的,您确实可以用 3.0 拆成多 match 中间加 limit 试试

另外,FIND PATH 可以考虑试试,如果您只关心路径,不关心路径中的属性(和MATCH一个区别是两边遍历,这里最重要的是可选不带 WITH PROP 没有属性省内存,缺陷是条件还只支持边属性的过滤)。

多谢,刚从2.6.1升级上来,没仔细看,find path应该更适合我的遍历场景,但是看到之前的帖子说find path内存比match占用的还多,没敢用,这边去试试看。现在的场景既关心路径,也关心路径中的属性,需要统计不同类型的点在路径中出现的次数。我再看看

1 个赞

嗯嗯那个情况是因为它是两边一起探索,如果带上属性运行时内存会大一些。

麻烦问一下 find noloop path from “vid1” to “vid2” over * bidirect upto 10 steps yield path as p limit 3;
不加limit能查出数据,但是加上limit,会报SyntaxError: syntax error near `limit’错误呢

因为数据量真的很大,但是发现limit不能接在语句后面,不太理解

LIMIT 要带上管道| limit 3 这样

:sob: 我意味[ | ] 代表有或者没有…中了正则的毒,抱歉

1 个赞

哈哈,这里的管道很像 shell 里的管道

find语句最后能不能拼接集合操作呢?尝试了几个用管道符拼接都不行

因为我设置了upto 10 steps,我需要展示路径最长的几条路径,但是order by的排序不是按照path的长度排序的,不知道怎么去limit,请教一下

麻烦问一下,有办法取出find路径中最长的前3条嘛?
辛苦了,麻烦回答一下

find noloop path from “vid1” to “vid2” over * bidirect upto 10 steps yield path as p| yield length($-.p) as len, $-.p as p|order by $-.len | limit 3

1 个赞

谢谢

如果你觉得 jmq2020 的回复解决了你的问题,可以勾选他的某条回复为解决方案哈~ 方便后续和你遇到相似问题的小伙伴可以快速找到答案,谢谢 nianquan 啦~

此话题已在最后回复的 30 天后被自动关闭。不再允许新回复。