执行一个look up语句,但一直是Storage Error: RPC failure, probably timeout

请问执行LOOKUP ON protein_protein YIELD edge AS e| YIELD COUNT(*) AS Number;
一直是这个问题Storage Error: RPC failure, probably timeout,是什么原因呢(这个边数量有6亿多,storage状态是online)

大概是捞取数据的时候,资源耗尽了。如果你只是做某个 tag / edgetype 的统计的话,可以试试 show stats SHOW STATS - NebulaGraph Database 手册

啊我就是想看看stats的值准不准,就想用这个语句看看两个值的有没有差别

如果只是验证 show stats 的可信度的话,你可以找多个数据量小点的 tag 来看看统计量。

但之前出现过有的tag准有的不准,(这次更新数据后也有submit job stats)单纯担心目前这个不准…

您好,我用match 语句查询,做了数量限制,也会出现Storage Error: RPC failure, probably timeout这个问题,请问是什么原因呢,謝謝~MATCH()-[e: protein_protein]->() return e limit 3

这个是常见的 match v:tag return v / match v:tag return v limit,都涉及了从全量数据中检索数据,是容易导致系统停止响应的语句。

目前来说 show stats 的可信性还是很高的,基本上没有出现过统计不准的事情,一般来说统计不正确的是原因有以下几种:

  1. 原始数据有重复,导致统计出来的数据比自己认为的多;
  2. 统计 stats 命令 submit job stats 发送之后,有新的数据变更,会导致 show stats 和实际情况有出入;

那请问怎样可以避免这种情况呢

第一种情况的话,就是要自己对源数据进行处理确保数据不重复;第二种的话,:thinking: 尽量选个写操作不频繁的时候做下统计。

啊谢谢解答,我还想知道 “match v:tag return v/match v:tag return v limit` ,都涉及了从全量数据中检索数据,是容易导致系统停止响应的语句” 有什么方法可以避免这种问题吗

如果你要做涉及到大量数据的查询的话,建议你对对应的 tag/edgetype 进行索引,你可以看看思为之前写得这篇文章:全方位讲解 Nebula Graph 索引原理和使用

好滴谢谢!
我发现一个事,studio 里show hosts 显示storage是online,但到容器里去看发现有一个storage是unhealthy的,这算是是状态不一致吗

studio 里的状态应该是包括服务 unhealthy 的,如果服务 unhealthy,对应的 studio 状态应该是 offline。

如果 studio storage offline 的话,有 3 种情况:

  1. 没有添加 hosts,即 add hosts 操作没有执行:add hosts 参考这个 管理 Storage 主机 - NebulaGraph Database 手册
  2. 本身的 storage 服务出现了问题;
  3. 可能 studio 显示的 storage 和你看的 unhealthy 的 storage 不是同一台;

:thinking: 第一种的话,你按照文档添加下命令就好;第二种的话,你可以重启下;第三种的话,你看下配置文件,调整下 ip 和端口号;

1 个赞

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