Match多跳查询的聚集点优化问题

[undefined]

• nebula 版本：3.4.1
• 部署方式：单机
• 安装方式： tar.gz
• 是否上生产环境：Y
• 硬件信息
• 磁盘（ 推荐使用 SSD）: 阿里云ESSD云盘 PL1
• CPU、内存信息：16核(vCPU) 128 GiB

问题的具体描述

通过上个帖子的问题：match多边类型查询优化实践
参考文档：增加和删除标签
迭代数据结构设计，将标签数据转成Tag用VID进行关联查询，结构设计如下：

CREATE TAG IF NOT EXISTS biz_node_tag(tag_id int, tag_type string, tag_name string);
CREATE TAG INDEX IF NOT EXISTS biz_node_tag_index on biz_node_tag(tag_id);

在小规模数据量的情况下可以获得一个更好的查询效率，查询语句如下：

MATCH p=(v:biz_node)-[e:`biz_edge`*2]->(v2:biz_node_tag)
WHERE id(v) == "ID-jwhE5Y9CSJ1zCbiNMvTW4U1mxwgrvX"
RETURN p
LIMIT 5;

执行效率从之前设计实践后的39s，降到最多7s，一般情况3s, 最低0.5s;

问题场景：
由于实际生产环境中，有很多点存在多流出边的业务繁忙点和超级聚集点，实际查询时间可能会到200s，或者直接把服务器内存撑爆的情况

数据情况：
biz_node：2亿；
biz_edge：5亿；
biz_node_tag：7800w;

解决方案：

• 超级聚集点可以通过拆分，将全量数据Tag的超级聚集点删除，重新用一个新的tag进行维护；
• 业务繁忙点属于业务日常查询数据范围，无法进行单独存储，所以暂未找到比较合适的办法进行规避，且这类数据已经在测试查询中会把服务内存直接撑爆的情况出现，需要讨论出以下几个问题：
  a. 是否是因为单机内存不足导致的查询效率过低；
  b. 如果升级单机内存之后是否还会出现撑爆服务器的情况；
  c. 如何科学的设计业务繁忙点的结构；
  d. 有什么经验可以优化这类高流出流入的查询效率；
  c. 超级聚集点的设计是否可行；
  e. 为什么nebula平时查询要么没动静，cpu和内存使用率都很低，复杂查询一来直接就爆，原理是什么；

[xtcyclist]

两种语句的资源用量往往会超出预期，一种是查询很复杂的，比如连了很多个 match 的，中间结果多，算子多，内部可能有笛卡尔积；另一种是查询很简单，没有过滤条件，没指定 tag，没指定 edge type，这种查询依赖全图扫描，在数据量大时会消耗很多资源。

正如你所说，像你写的这条查询的实际执行开销是不稳定的，依赖相应的图拓扑结构。

要么设置一个参数（max_edge_returned_per_vertex）对超级节点做截断，通过牺牲准确度来换取低资源占用，参考：Storage 服务配置 - NebulaGraph Database 手册

要么考虑改写查询，减少对图拓扑的依赖，此处可能还需要同时优化建模方式。

[MuYi]

如之前交流：

1. 需要修改下VID的设定值为合理值；
2. partition的设定为合理值
   以上文档里均有描述

上面的一些优化其实文档里也有一部分最佳实践，建议先看下

图建模 - NebulaGraph Database 手册