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

我们有一个需求是计算某个点关联的边的总个数,现在采用的查询是先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,万兆网卡

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

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

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

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

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

是的.

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

@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 团队有什么好建议,优化参数,或者方案吗

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

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

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

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

2 个赞

浙ICP备20010487号