使用GO语句查询Count性能低的问题

问答 讨论
,
1

我们有一个需求是计算某个点关联的边的总个数，现在采用的查询是先go再用管道聚合计数的方式：

GO FROM hash("vertex_id_120001") OVER edge_type_1 | yield count(*)

上面这个语句，count结果为420万+，共耗时5s，后续可能点的边数据还会扩充10倍以上，达到4000万级别，这个性能在业务上会有些无法接受

请问性能调优这块，是否有什么参数，可以加快查询效率？ 目前机器资源仍空闲很多

或者如何定位查询瓶颈的位置？ 据我所知1.1.0无法查看执行计划

Nebula版本：1.1.0

机器配置：16核,48G,NVME,万兆网卡

2

我理解 这种场景 应该离线计算？ 实时计算这么大的数据量快不了

3

这个只是看似数据量大，但实际我只是要一个count数字而已，并不需要真正去返回所有数据

4

@jude-zhu 这个可以考虑2.0支持 所有下推的地方这些接口都需要修改

5

1.0没有下推count 所以慢 想优化这块得改代码逻辑

6

请问目前1.1.0版本的逻辑，是storaged返回所有点边数据给到graphd，然后在graphd中再做下一个管道操作count吗

8

是的.

9

感谢各位大佬回复：） 这块如果可以优化对我们会很有帮助，因为我们有很多这种需求，不需要返回原始数据，只是在图数据库中进行计算出单个统计的数值

10

@jievince @critical27 你们好，请问两位，我司在调研方向也遇到类似的场景，对于 TAG 对 TAG 之间存在千万级别的 EDGE，这种查询场景，效率上怎么解决

如：

点与数量级

TAG_A:   500W
TAG_B:   10
TAG_C:   10

边及数据量

EDGE_B_to_A : 数量边，百万级别
EDGE_C_to_A : 数量边，百万级别

伪代码查询语句

(
go from hash("B") over EDGE_B_to_A YIELD EDGE_B_to_A._dst AS id
INTERSECT 
go from hash("C") over EDGE_C_to_A YIELD EDGE_C_to_A._dst AS id
) | yield count(*)

这种场景，我们公司在实践中，发现查询IO超时（ i/o timeout ）

对于这种场景，nebula 团队有什么好建议，优化参数，或者方案吗

在此，先十分感觉你们对于开源社区的贡献

11

在1.0版本中是否有临时性的解决方案呢

12

暂时没有有效的临时方案，要支持得修改代码逻辑，把count下推。

13

请问 @critical27 sw哥，咱们 count push down 现在做了么？

2 个赞