乐趣区

关于图数据库:详解-nebula-20-性能测试和-nebulaimporter-数据导入调优

jiezi

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

0. 概要

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

我把本人测试的过程整顿一下，心愿对大家有一点启发，如果大家有更好的意见，请不吝赐教！

1. 部署 Nebula 集群

首先筹备了 4 台实体机：1、2、3、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 报名传送门，咱们在北京等你来交换~~

退出移动版