Nebula 性能问题排查和性能调优

当我们使用 Nebula 图数据库执行查询语句，效率不如预期时候可能会有多种因素影响，可以分为两类，第一种是硬件资源受限，第二种是执行计划的问题（涉及到索引的选择、执行语句的优化等等），而本文着重讲述这两种情况下的性能问题排查。

本文测试环境最低硬件要求

硬件检查大体分为内存检查、磁盘 IO 检查、网络带宽检查和 CPU 检查等四类检查。

在执行查询语句时，在目标机上使用 top
命令查看 nebula-graph 进程和 nebula-storage 进程的内存使用情况

 free
命令可以查看内存的整体状态

如上图所示，pgpgin/pgpgout
就是内存的换入换出；majflt
是主缺页中断。

分析磁盘 IO 的工具很多，我们选择其中一个 iostat
命令, 可以同时监测 CPU 和磁盘 IO 的使用情况。

通过上述指标可以判断瓶颈是否在 IO 排队上。

对数据密集型服务，网络带宽可能成为瓶颈。首先查看服务器的网卡带宽配置，使用 ethtool  <网卡名>。  (一般第一块网卡命名为 eth0，第二块为 eth1)

使用 top
命令查看 CPU 的运行指标。

profile
可以查看执行语句在 Nebula 中的详细执行计划，包括每个算子的执行时间。

其中和 storage
 交互的算子主要有 getNeightbor
、getVertices
、getEdge
和 indexScan
。下图为 getVertices
算子的详细情况

在多分区场景下 ：

同理，GetNeightbor
和 GetEdge
可以同样参考上述方式进行分析。

近日在论坛中看到有用户发帖，为什么几乎相同的两条语句，一条 LIMIT
可以下推到 storage 中，另一条却无法下推到 storage 中，在此稍作解释。

目前 Nebula 中使用的是基于 RBO 的优化 https://nebula-graph.com.cn/posts/nebula-graph-source-code-reading-04/，优化阶段是基于已经写好的优化规则进行优化的，优化器并不能看到整体的执行计划，而是从根节点开始递归的遍历到叶子节点，然后再从叶子节点一个个和已经写好的规则进行匹配。如果当前遍历到的节点及其依赖节点和某一个规则匹配，则执行转换；否则继续，直到递归结束。

目前已有的规则参考源码：https://github.com/vesoft-inc/nebula/tree/master/src/graph/optimizer/rule

这里举一个例子方便理解，首先把 nebula-graph.conf
中 enable_optimizer
设置为 false，这时候执行计划是不经过优化器的。下面对比

• GO FROM "tim" OVER like YIELD $^.person.name, like._dst | LIMIT 3
  

• GO FROM "tim" OVER like YIELD $$.person.name, like._dst | LIMIT 3
  

这两条语句最原始的执行计划

GO FROM "tim" OVER like YIELD $^.person.name, like._dst | LIMIT 3
  的执行计划如下

在优化器中从根节点 DataCollect
 出发遍历到 Start
节点，然后一个个匹配，当遍历到 LIMIT
节点时，匹配到 project→ limit
规则，执行转换将 LIMIT
放到 project 前面变为 limit→project
，然后继续 LIMIT
节点匹配到 getNeighbors→limit
规则，将 LIMIT
下推到 getNeighbor
中，完成 LIMIT
下推。

GO FROM "tim" OVER like YIELD $$.person.name, like._dst | LIMIT 3
  的执行计划如下

在优化器中从根节点 DataCollect
出发遍历到 Start
节点，然后一个个匹配，当遍历到 LIMIT
节点时，匹配到 project→ limit
规则，执行转换将 LIMIT
放到 project
前面变为 limit→project
，但是不存在 leftJoin→limit
规则，因此无法将 LIMIT
继续下推

因此虽然两条语句的 YIELD
子句只相差了一点，一个是取起始点属性，一个是取目的点属性，但是原始的执行计划却相差很大，造成优化后一个 LIMIT
下推，另一个却没有，造成性能问题。

索引是否命中对查询性能的影响也非常大，Nebula 的索引介绍请参考文章：https://nebula-graph.com.cn/posts/how-indexing-works-in-nebula-graph/

Nebula 中的索引分为唯一索引（索引列的值必须唯一）和联合索引（多个字段上建立的索引，能够加速复合查询条件的检索）。其中联合索引遵循最左前缀原则，即在检索数据时从联合索引的最左边开始匹配，目前 Nebula 不支持跨 tag 或者 edge 创建复合索引。

不能使用索引的条件有

1、负向条件查询, 例如 WHERE
条件中有 !=、not in

2、模糊查询, 例如：like '%XX'

在 validate 阶段会将 MATCH
 语句中的 WHERE
条件和点和边属性过滤提取出来，然后在 optimizer
阶段会对提取出的条件进行分析：

若过滤条件时候会在选择一个和当前 Schema 相同的索引中属性列最少的索引进行全表扫描，否则进入到 2；

对当前条件进行分析, 目前仅支持单一的逻辑表达式，例如 where c1 > 1 and c2 < 2 and c3 == 1
  或者 where c1 == 1 or c2 == 1 or c3 == 1
，不支持复合的逻辑表达式，例如 where c1 > 1 and c2 > 1 or c3 > 1
或者 where c1 > 1 and c2 < 2 or c2 > 1
等等，当满足单一逻辑表达式后，进入到 3；

索引选取的优先级时等值查找 > 范围查找，其中索引中的列命中条件中的列数越多，优先级越高；

建议：

1、建联合索引的时候，区分度最高的字段在最左边

2、存在非等号和等号混合判断条件时，在建索引时，请把等号条件的列前置

讲完硬件和执行计划，再来讲述下常见的 Nebula 使用性能瓶颈点，它们主要集中在配置以及使用操作方面。

storage.conf 配置

• rocksdb_block_cache：数据在内存缓存大小，默认是 4MB，可以设置到当前内存的一半，这样在第二次查询的时候，可以优先在 RocksDB 的 cache 中查找数据；

• query_concurrently：true 时 storage 会并发地捞数据，false 时 storage 是单线程捞数据；

• rocksdb_column_family_options：在刚开始导入大量数据时可以将 disable_auto_compaction
  选项设置为 true，提升写入的性能；

graphd.conf 配置

• system_memory_high_watermark_ratio：设置内存使用量超过多少时停止计算，以 1 作为单位一般设置为 0.8～1.0 之间

Compaction

当导入完数据之后需要执行。

• 打开 nebula-console 连接到图空间，然后执行 SUBMIT JOB COMPACT
  ;

• 通过 SHOW JOBS
   查看 compact 是否执行完毕。

compaction 可以消除重复的数据，去掉无用的数据，将 sst 文件合并，进而减少 sst 占用的磁盘空间，提高读的性能。

Balance leader

• 打开 nebula-console 连接到图空间，然后执行 BALANCE LEADER
  ;

• 通过 S
HOW HOSTS
   查看 leader 是否均匀分布。

Balance 可以让 storage 服务实现负载均衡，避免出现热点现象。

以上为本次分享。