乐趣区

关于nebula:实操适配-NebulaGraph-新版本与压测实践

jiezi

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

前言

NebulaGraph v3.1 版本曾经公布有一段时间了，然而咱们的我的项目之前是基于 v2.6.1 版本开发的，因为始终在做性能相干的工作，所以始终没有对图库进行降级。

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

降级事项

v2.6.1 版本到 v3.1.0 版本是一个较大版本，从不反对间接降级来看，改变的货色还是蛮多的，那么我的项目中须要革新的中央应该也是比拟多的。下边是咱们在降级过程中的一些总结。

语法改变

  1. 首先是 MATCH 查问的调整，优化了 MATCH 的查问性能，并且反对多 MATCH 的子句，这个的确极大地提高了 MATCH 查问的表达能力，然而实测当中，简单的查问性能并不会太高，用于不须要毫秒级响应的查问剖析还是很不便的。
  2. MATCH 查问属性须要指定 Tag，这个肯定水平上解决了同名属性的问题，顺带提一下在 GO 语句中，同名属性尚未解决，用的时候须要留神。
  3. match (v) return v 这个切实是太有用了，之前必须要指定 vid，然而很多时候导入了数据不晓得 vid，只想大抵看一下，还要去翻一下数据很麻烦。
  4. GO 等语句必须要带 YIELD 返回了，之前我的项目中所有用到的中央都要做批改，这个要留神。
  5. GO、FETCH 等能够返回 vertex 和 edge 了，这个也解决了一大痛点，因为 API 查问须要返回 path 或者 vertex 和 edge，用于渲染图，然而 v2.6 中 MATCH 的查问太慢了，只好应用 GO 查问。于是，就要把点边的所有信息都 YIELD 进去，造成特殊化的返回，须要专门写代码解析。当初能够间接一次返回 vertex 和 edge，应用通用的解析办法很 easy 了。
  6. SHOW ALL QUERIES 变动了，我的项目中有用到超时 kill 的机制，须要 kill 掉慢查问，当初要改成 show local queries，拿到 sessionId（ps：这个 sessionId 公有了，要不就不必查了 …），再应用 SHOW QUERIES 查问到对应的 planId 执行 kill 命令。
  7. Console 的查问数据导出曾经不可用了，有用到的须要留神。

新增局部

  1. KV 拆散 是一个很大的扭转了，不过目前没有对这个性能进行测试，有实际过的能够谈谈未分离的差别。
  2. 减少了 限度一个用户和机器的 session 个数，这个不留神的话在并发的状况下很容易超出限度。
  3. 反对了 CLEAR SPACE，革除图空间语句，这个十分好用，在测试时常常要清空图库，以前只能删除重建。不过实测中数据量较多会有肯定耗时，须要审慎应用。
  4. BALANCE DATA 这个命令不间接可用了，论坛问了一下须要关上试验性功能。因为关上了试验性功能，所以间接开启了 v2.6.0 开始反对的 TOSS 这个性能，强制保证数据一致性，导致数据写入迟缓，于是就又关掉了。所以目前 BALANCE DATA 不太不便，可能后续会有一些调整吧。

改变局部

  1. 删除点只会删掉点了，之前是连带点的边都会删除，这里应用肯定要留神悬挂边导致的数据一致性的问题。
  2. 反对不带 Tag 的点，就是容许只有一个 vid 存在。这个仿佛引起一个 bug，只有一个 tag 的点在 TTL 过期之后，点依然存在，跟文档不符。另外 TTL 的工夫也仿佛是一个 bug，总是提前个 30 几秒就过期了，比方设置 60 秒，再 30 秒左右就过期了。
  3. ADD HOSTS 命令，用于增加 storage 服务，这样就能够较好的治理 storage 节点了，然而 BALANCE DATA 命令应用的问题，导致扩缩容没有 2.6 版本不便了。
  4. 会话超时工夫必须要限度了，实测中 session 那里可能是有一个 bug，session 被程序 release 之后没有革除，导致触发了最大 session 数，所以就将 session 超时工夫改小一点，清理掉不必的 session。
  5. 修复了大量会引起解体的语句，之前的一些聚合语句使用不当就会引起解体，着实有点吓人 …

适配层面大抵总结这么多吧，还有一些改变就不再细说了，这里讲到的都是在理论中应用时的感触。

压测实际

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

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 也大量报错退出了。

呈现 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 使用率也不高，然而怎么优化都下不来，起初才发现网络有问题，着实有点坑。

总结

整体来说，v3.1.0 版本做了很大的改良，无论是新性能还是语法上，都做了很好的扭转，然而基于下面的问题，感觉在稳定性上要弱于 2.6 版本。可能也是因为 v3.x 版本在底层上的改变比拟大，呈现这些问题也无可避免的，心愿在今后的版本中有能较好的优化，好的产品当然是须要一直打磨的。

另外，如果上边提到的问题你有更好的见解也欢送来探讨，也心愿这些问题可能帮忙官网人员进行更好的优化。

谢谢你读完本文 (///▽///)

无需懊恼降级问题，当初能够用用 NebulaGraph Cloud 来搭建本人的图数据系统哟，快来节俭大量的部署安装时间来搞定业务吧~ Nebula Graph 阿里云计算巢现 30 天收费应用中，点击链接来用用图数据库吧~

想看源码的小伙伴能够返回 GitHub 浏览、应用、(^з^)-☆ star 它 -> GitHub；和其余的 NebulaGraph 用户一起交换图数据库技术和利用技能，留下「你的名片」一起游玩呢~

退出移动版