Star

在有环图中使用GO语句查询全部可达节点时指定最大跳数带来的性能问题

  • nebula 版本:nebula 1.1.0
  • 部署方式:单机
  • 硬件信息:内存:64G,500GB SSD
  • 问题的具体描述

我创建了space并导入了样例数据,在使用GO语句查询一个点相关的连通图的时候,遇到了查询性能问题,查询到的连通图可能存在环,并且最大跳数不受限制。

查询的图包含了一种TAG和一种EDGE
TAG:bundle
EDGE: bundle_direct_dependencies_bundles
该EDGE是两个bundle之间的单向边。

图中存在环,图中点之间会有多跳(最多可达15跳),但也可能将会更多。
我的期望目标是:查询指定bundle节点依靠bundle_direct_dependencies_bundles边的全部可达节点,包括间接可达的节点。

GO 1 TO M STEPS FROM hash("123456786479.bytes") OVER bundle_direct_dependencies_bundles YIELD DISTINCT YIELD DISTINCT bundle_direct_dependencies_bundles._dst;

问题就在于上面语句中M的取值,它应该是连通图中最远两顶点之间的的最大跳数,但我尝试为M取一个尽可能大的数值时(比如取10),查询耗时变得非常的漫长,需要非常久才返回结果。但如果M取小的值,查询将不符合我的初衷(查询该节点所在的全部可达节点,包括间接可达的节点)。我想求助一下,nebula是否有更好的方式原生的支持这种查询需求,否则我将需要在程序中多次查询来实现。

你那边能统计一下 一起有多少点、边, 10跳 的性能是多少?

bundle包含14000个点,bundle_direct_dependencies_bundles包含43000条边,我尝试查找的连通子图包含了140个点,存在很多环,测试数据如下:

GO 1 TO M STEPS FROM hash("123456589982.bytes") OVER bundle_direct_dependencies_bundles  YIELD DISTINCT $$.bundle.bundle_name

M=4,执行时间消耗 0.029426 (s)
M=5,执行时间消耗 0.076997 (s)
M=6,执行时间消耗 0.132618 (s)
M=7,执行时间消耗 1.326229 (s)
M=8,执行时间消耗 14.774355 (s)
M=9,Studio查询timeout
M=10,偶尔数据库进程会挂

1赞

能否统计一下第 8 步大概有多少的顶点集合返回?

GO 1 TO 8 STEPS FROM hash("123456589982.bytes") OVER bundle_direct_dependencies_bundles YIELD bundle_direct_dependencies_bundles._dst | YIELD COUNT(*)

在第6步的时候已经查找到全部的141个节点,后面的步骤没有找到新的节点,图中存在比较多的环。

了解了,1.0 的 GO 代码中是没有处理去重的操作的,也就是访问过的顶点还是会重复访问,这里可以是个优化点。像你所述的情况当没有新的顶点再次加入到访问集合中,应该就不必往外探索,即 6 步之后的所有步应该都是一样的时间。

@jmq2020 在 nebula 2.0 中的 M 到 N 步可以考虑是否加入类似的优化!

这功能感觉可以有哦,谢谢解答

您好,你的需求可以通过子图解决,但是子图只在2.0上支持,1.x原则上不再增加新的功能,您可以尝试一下2.0, 2.0相对于1.x新增的很多新的功能

谢谢解答,我换到2.0试试

浙ICP备20010487号