详解 nebula 2.0 性能测试和 nebula-importer 数据导入调优

这是由社区用户——繁凡撰写的一篇他的实践分享，主要讲解如何进行 Nebula 性能测试以及数据导入部分的性能调优。下文中出现的“我”代指用户繁凡。

0. 概要

以前在作 Nebula 的调研工做，而后又针对使用上作了性能测试，期间屡次请教了 Nebula 的官方人员，在这里对官方人员表示感谢，大佬辛苦了！

我把本身测试的过程整理一下，但愿对你们有一点启发，若是你们有更好的意见，请不吝赐教！

1.部署 Nebula 集群

首先准备了 4 台实体机：一、二、三、4，每台配置，CPU：96C，内存：512G， 磁盘：SSD。机子分配：

• 1：meta，storage
• 2：storage
• 3：storage
• 4：graphd

安装过程就再也不详述了，使用的是 rpm 的方式。其余插件：nebula-import-2.0，nebula-bench-2.0，下载源码编译便可，安装在 4 节点。

2.导入数据

本次导入的数据数据结构为 7 种点类型、15 种边类型，数据量并不大，结构也很简单，数据量总计 3400w，不过要提早处理成这么多个点边表。

先建立 space，设置 vid=100 ，replica_factor=3，partition_num=100。

nebula-importer 数据导入优化

使用 nebula-importer 进行导入，直接开干，速度只有 3w/s 的样子，这也太慢了吧。查看import的文档，整个使用的参数也就只有concurrency，channelBufferSize ，batchsize

先调整一下试试吧，随便改了改，效果并不明显, 发帖请教大佬了。详见论坛帖子 nebula-import 2.0 导入速度太慢，请教完以后，收获很大，先改 yaml 参数

concurrency：96 # cpu核数
channelBufferSize：20000
batchsize：2500

复制代码

速度差很少 7-8w 了，嗯，看起来确实快了不少，再搞大点，graphd 直接崩掉了，看来仍是不能过大，因此这几个参数要尽可能大可是不能过大。

而后再确认下磁盘和网络，居然用的是机械磁盘和千 M 网络。。。改为SSD的，而后再切换成万 M 网络，速度直接再提高一倍多，大概 17w/s，看起来硬件仍是很重要。

而后我再想会不会跟数据有关系，注意到 vid 和partition_num，vid 挺长的想着设置短一点可是没办法改，由于确实有这么长的，而后是 partition_num，看了下官方说明，磁盘的 2-10 倍，改成了 15，确实有影响，速度达到了 25w/s。到这里也算比较满意了，可能再修改还会有提高，不过已经知足要求了先告一段落吧。

小结

• concurrency 设置为 CPU 核数，channelBufferSize 和 batchsize 尽量大，可是不能超过集群的负载。
• 硬件要用 SSD 和万 M 网络
• space 的分区 partition_num 要合理，不能太多
• 猜想 vid 长度，属性数量，graphd 的个数都有影响，但还何尝试

3.压力测试

根据业务上使用的指标，选取了一个进行测试。 指标以下：

match (v:email)-[:emailid]->(mid:id)<-[:phoneid]-(phone:phone)-[:phoneid]->(ids:id) where id(v)=="replace" with v, count(distinct phone) as pnum,count(distinct mid) as midnum,count(distinct ids) as idsnum , sum(ids.isblack) as black  where pnum > 2 and midnum>5 and midnum < 100 and idsnum > 5 and idsnum < 300 and black > 0 return v.value1, true as result
复制代码

该语句为一个三度扩散 + 条件判断，集中数据涉及点的数量大概在 200-400 之间。

官方的 nebula-bench 须要作一点修改，打开 jmter 的 go_step.jmx 配置文件，修改ThreadGroup.num_threads为 CPU 核数，而后是其余的参数，如 loop，ngql 根据实际状况设置，ngql 里边的变量要用 replace 代替。

因为测试数据为较为集中的数据，该部分测试结果为 700/s,将数据扩大至所有节点，则达到 6000+/s。并发看起来仍是能够的，查询速度也 ok，最高 300ms。

由于我这里是单节点，因此想增长 1 台 graphd 进行测试，看并发是否提升，而后直接启动了一个graphd进程，再测试结果发现没有提升。

而后恰好看到发布了2.0.1，因此从新搭建了集群，从新导入数据，使用 3 台 graphd，性能直接翻三倍，集中数据达到2100+/s，所有节点则达到将近 2w。因此很奇怪，详见论坛帖子nebula-bench 2.0 增长graph节点，并发上不去 。

猜想多是因为增长 graphd 以后没有 blance 或者 compact，有空能够尝试一下。

另外因为没有使用一些监控组件，只用了 Linux 的命令查看，因此也没有获得太确切的机器状态信息。

小结

• 测试以前，保证集群的负载平衡，作好 compact
• 适当调整 storage 的配置，增大可用线程数以及缓存的内存大小
• 并发跟数据有很大关系的，单纯多少没有意义，须要结合本身的数据分布状况来看。

4.配置

下边直接贴一下我修改的参数，meta，graphd 都采用默认配置，也没有特别要修改的，只贴一下 storage，并进行说明。

rocksdb_block_cache=102400  # 官方建议 1/3 内存，我这里设置 100G
num_io_threads=48 # 可用线程数，设置为 cpu 核数一半
min_vertices_per_bucket=100 # 一个桶最小的点数量
vertex_cache_bucket_exp=8 # 桶的总数是 2 的 8 次方
wal_buffer_size=16777216  # 16 M

write_buffer_size:268435456   # 256 M
复制代码

这里的参数是根据浏览各个贴子以及去官方代码查找的，并不必定特别准确，也是摸索来的，其余的参数没有特别修改。有不少的参数没有暴露出来，官方不建议随便修改，因此须要了解的话要去 GitHub 的源码里边查看。

结尾

整体来讲，本次测试算不上特别专业，可是针对具体业务场景的测试，Nebula 也表现了很好的结果。具体参数的调整，也没有研究特别透彻，须要以后在使用中研究，若是你们有调优的好想法还请畅所欲言。

交流图数据库技术？报名参与 Nebula 交流会，NUC·2021 报名传送门，咱们在北京等你来交流~~