match语句性能过低

  • nebula 版本:2.6.1
  • 部署方式:单机
  • 安装方式:源码编译
  • 是否为线上版本:N

抱歉数据比较敏感,问题大致概述如下。用match和lookup实现相同的功能,语句大致如下:match (n : id) return n limit 1 和 lookup on id yield properties(vertex) limit 1。lookup能完美得到结果且响应很快,但match会报错error 1005: storage error: part : 10, error : E_RPC_FAILURE(-3)。看了官方文档,说基于索引查询会大幅降低性能。但目前工作需要做全局查询,所以有适合match的语句可以使用吗?match语句可以再优化吗?或者其他go等语句能实现match功能吗?谢谢

这个问题是解决了吗?

算是解决了吧,同样的命令我在nebula测试数据basketball运行无任何问题,所以我理解就是实际数据太大了,导致返回不了结果?所以还是想问一下这个具体是什么问题呢?有办法解决吗,是不是就是单纯的配置不够? error 1005: storage error: part : 10, error : E_RPC_FAILURE(-3)

数据
点:1.6亿
边:2.2亿

配置
32core,256内存,2T ssd,单机

这个问题主要是咱们 match 的下推还没有做完(非常抱歉,我们在努力做这一块哈,会尽快做完的),导致 limit 在 match 的情况下,存储层没能根据条件 filter 去做剪枝,所以它的 effort 还是像 match (n : id) return n 一样大。

这个情况下可以参考 常见问题 FAQ - Nebula Graph Database 手册

很大可能是 graphD 上的 storage client 访问超时了哈

1 个赞

其实limit也不影响,我本来就是想做全局查询的,所以可以修改storage client的默认配置吗?还是只有通过提高配置才能实现了?

您猜的没错,可以修改超时的时间一定程度上缓解的

如何处理错误信息 Storage Error E_RPC_FAILURE¶
报错原因通常为 Graph 服务向 Storage 服务请求了过多的数据,导致 Storage 服务超时。请尝试以下解决方案:

  • 修改配置文件:在nebula-graphd.conf文件中修改–storage_client_timeout_ms参数的值,以增加 Storage client 的连接超时时间。该值的单位为毫秒(ms)。例如,设置–storage_client_timeout_ms=60000。如果nebula-graphd.conf文件中未配置该参数,请手动增加。提示:请在配置文件开头添加–local_config=true 再重启服务。
  • 优化查询语句:减少全库扫描型的查询,无论是否用LIMIT限制了返回结果的数量;用 GO/Lookup 语句改写 MATCH 语句(前者有优化,后者无优化)。
  • 检查 Storaged 是否发生过 OOM。(dmesg |grep nebula)。
  • 为 Storage 服务器提供性能更好的 SSD 或者内存。
  • 重试请求。
2 个赞

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