「实操」适配 NebulaGraph 新版本与压测实践

本文来自邦盛科技-知识图谱团队-繁凡，本文以 NebulaGraph v3.1.0 为例。

前言

NebulaGraph v3.1 版本已经发布有一段时间了，但是我们的项目之前是基于 v2.6.1 版本开发的，由于一直在做功能相关的工作，所以一直没有对图库进行升级。

最近，刚好完成了 NebulaGraph v3.1 版本的升级，并做了一些测试工作，这期间的一些问题总结，在这里分享一下，都是实践中踩过的坑，文中的一些问题可能也是 NebulaGraph 相关的 bug。

升级事项

v2.6.1 版本到 v3.1.0 版本是一个较大版本，从不支持直接升级来看，改动的东西还是蛮多的，那么项目中需要改造的地方应该也是比较多的。下边是我们在升级过程中的一些总结。

语法改动

首先是 MATCH 查询的调整，优化了 MATCH 的查询性能，并且支持多 MATCH 的子句，这个确实极大地提高了 MATCH 查询的表达能力，但是实测当中，复杂的查询性能并不会太高，用于不需要毫秒级响应的查询分析还是很方便的。
MATCH 查询属性需要指定 Tag，这个一定程度上解决了同名属性的问题，顺带提一下在 GO 语句中，同名属性尚未解决，用的时候需要注意。
match (v) return v 这个实在是太有用了，之前必须要指定 vid，但是很多时候导入了数据不知道 vid，只想大致看一下，还要去翻一下数据很麻烦。
GO 等语句必须要带 YIELD 返回了，之前项目中所有用到的地方都要做修改，这个要注意。
GO、FETCH 等可以返回 vertex 和 edge 了，这个也解决了一大痛点，由于 API 查询需要返回 path 或者 vertex 和 edge，用于渲染图，但是 v2.6 中 MATCH 的查询太慢了，只好使用 GO 查询。于是，就要把点边的所有信息都 YIELD 出来，造成特殊化的返回，需要专门写代码解析。现在可以直接一次返回 vertex 和 edge，使用通用的解析方法很 easy 了。
SHOW ALL QUERIES 变化了，项目中有用到超时 kill 的机制，需要 kill 掉慢查询，现在要改成 show local queries，拿到 sessionId（ps：这个 sessionId 私有了，要不就不用查了…），再使用 SHOW QUERIES 查询到对应的 planId 执行 kill 命令。
Console 的查询数据导出已经不可用了，有用到的需要注意。

新增部分

KV 分离是一个很大的改变了，不过目前没有对这个功能进行测试，有实践过的可以谈谈未分离的差异。
增加了限制一个用户和机器的 session 个数，这个不注意的话在并发的情况下很容易超出限制。
支持了 CLEAR SPACE，清除图空间语句，这个非常好用，在测试时经常要清空图库，以前只能删除重建。不过实测中数据量较多会有一定耗时，需要谨慎使用。
BALANCE DATA 这个命令不直接可用了，论坛问了一下需要打开实验性功能。因为打开了实验性功能，所以间接开启了 v2.6.0 开始支持的 TOSS 这个功能，强制保证数据一致性，导致数据写入缓慢，于是就又关掉了。所以目前 BALANCE DATA 不太方便，可能后续会有一些调整吧。

改动部分

删除点只会删掉点了，之前是连带点的边都会删除，这里使用一定要注意悬挂边导致的数据一致性的问题。
支持不带 Tag 的点，就是允许只有一个 vid 存在。这个似乎引起一个 bug，只有一个 tag 的点在 TTL 过期之后，点仍然存在，跟文档不符。另外 TTL 的时间也似乎是一个 bug，总是提前个 30 几秒就过期了，比如设置 60 秒，再 30 秒左右就过期了。
ADD HOSTS 命令，用于添加 storage 服务，这样就可以较好的管理 storage 节点了，但是 BALANCE DATA 命令使用的问题，导致扩缩容没有 2.6 版本方便了。
会话超时时间必须要限制了，实测中 session 那里可能是有一个 bug，session 被程序 release 之后没有清除，导致触发了最大 session 数，所以就将 session 超时时间改小一点，清理掉不用的 session。
修复了大量会引起崩溃的语句，之前的一些聚合语句使用不当就会引起崩溃，着实有点吓人…

适配层面大致总结这么多吧，还有一些改动就不再细说了，这里讲到的都是在实际中使用时的感受。

压测实践

切换到新的版本，当然要进行一下压测，以发现一些没有排查到的问题，下边就直接上干货，讲一下实际遇到的问题。

SST 数据导入问题

由于 v2.6 的时候没有使用过 SST 导入，所以压测时为了快速导入数据，想使用 SST 去导入数据。

图库分片 partition 为 20，导入配置先设置了 repartitionWithNebula: false，结果发现产生了巨多的 SST 文件，ingest 极慢，并且出现数据写入丢失的问题。

然后调整为 ture，并调低了 spark.sql.shuffle.partitions，于是每个文件合并为了一个 SST 文件，很快就导入了。然后又产生新的问题，发现有一些点不存在了，没有导入成功，但是 SHOW STATS 统计信息正常。

经过反复测试与官方人员沟通，发现是 8 位长度的 vid 有问题，hash 的策略不太对，目前已经被修复了但是好像还未合并到主分支吧。具体可以看帖子：https://discuss.nebula-graph.com.cn/t/topic/8984/14

Client 数据导入问题

Client 理论上是不会有问题的，毕竟是语句写入，但是跟使用的方式和图库状态也有很大的关系。我是沿用了当时 v2.6 的配置文件，core：40，batch：2560 的配置。

图库冷启动写入报错：一开始就遇到图库冷启动的问题，冷启动之后立马导数，会写入报错：

E20220607 11:02:41.447904 108593 StorageAccessExecutor.h:39] InsertEdgesExecutor failed, error E_LEADER_CHANGED, part 17
E20220607 11:02:41.447954 108591 QueryInstance.cpp:137] Storage Error: Not the leader of 17. Please retry later.

但是这个问题不要紧，图库能自己恢复，过一会就写入正常了，error 语句会在最后被再次写入。（PS：这里注意下，error 语句写入的 write 方法中文会乱码，导致再次写入出错，我顺手改了一下已经提过 PR 了。）

raft buffer full 问题：使用上边的配置，导数并发太快，导致图库报错 raft buffer full，这个感觉是内存中的数据没有被快速 fush 到磁盘中，导致写入中止。于是调整配置，减小 core，batch，图库修改 write buff number 为 8，增大 buffer，发现 TOSS 开着，想着是不是为了保证一致性所以 flush 会慢？不太确定于是关掉了。还有一点是当时没发现，后来总结的时候才想到的，因为机器的网络有点问题，其中一台用了百 M 宽带，会不会是网络 IO 阻塞影响的，也不是很确定。（PS：网络真是个大坑，后边还会遇到，一定要检查带宽。）不过在进行了上边的修改之后，没有再报错了。

高并发导数，图库E_LEADER_LEASE_FAILED

这个问题一共遇到两次，一次是在导数结束后立马发起另一个导数任务，查看到语句大量报错，于是手动查询图库，发现任何查询都报错。

(root@nebula) [trans]> match (v) return v limit 10

[ERROR (-1005)]: Storage Error: part: 22, error: E_LEADER_LEASE_FAILED(-3531).

Tue, 07 Jun 2022 22:01:46 CST

尝试执行 BALANCE LEADER，执行总是 failed，尝试 Compaction 进行恢复，查询发现一会报错 Not the leader of 17. Please retry later. 一会能展示结果，并没有完全恢复，无奈只能重启解决。

第二次遇到是在进行压测的同时，使用 NebulaGraph Exchange 导数，看会有什么影响，结果再次出现该问题，Exchange 的 task 也大量报错退出了。

Errors

出现 E_LEADER_LEASE_FAILED 的问题会导致图库基本不可用，且不会自己恢复，个人猜测并发读写太大导致部分数据混乱，引起查询不可用。该问题目前尚未完全找到原因，所以使用时要稍微注意，导数的 batch 不要太大了，并发也要控制。帖子地址：https://discuss.nebula-graph.com.cn/t/topic/9013/13

其他问题

重启存在 offline：关闭时需要确保完全关闭再启动，慎用 restart。数据较多时关闭并不会马上关闭，需要等待一段时间，这时启动可能会有一台 storage 启动不起来或者报错，显示 offline，应该是 stop start 间隔太短，出现这种情况应该完全关闭后，ps 无进程再删除 storage 的 pid 再启动。

重启无分片：图库重启后总是出现一个 storage 节点某些图库无分片的情况，导致查询这台机器不干活，有点奇怪，只能 BALANCE LEADER 使其平衡。

网络问题：在上边提到过，一定要确保带宽，否则查询的执行计划里边，RPC的时间很大，影响查询速度。并发查询时发现延迟很高，CPU 使用率也不高，但是怎么优化都下不来，后来才发现网络有问题，着实有点坑。