主流开源分布式图数据库Benchmark

您好 Yangmeng,

可以参考这两个帖子, Yee 分别 给的一些解释

我引用一下 Yee 老师在两个帖子的信息

对于csv文件,importer读它是一个线程,启动concurrency个 client,每一个client有channelBufferSize size的queue来buffer query
The batchSize is the number of vertices or edges sent to nebula at the same time. Nebula Storaged will store these data in batch to avoid too many RPCs. The speed of inserting data is affected by your disk. So you can do some tests to find a suitable value.

看起来您的 10/10 是没有到storaged的处理极限,50/50也不知道有没有到极限,可以试着给定 cores数量的 concurrent数, batchSize再调大一些(超过50)评估一下速度,我建议把CSV截断为十分钟可以看结果的量级,不断逼近优化一下结果,然后share出来你的结果哈。

好的, 我的机器是88core, 754内存, 12T 高性能本地SSD, 那我就安装下面的再测试2组看看效果, channelBufferSize 这个参数我理解就是一个定长队列, 排满了就阻塞等待, 这个应该对速度影响不大,
batchszie这个我理解就是一个批的事务提交量, 按照以往的经验,这个的大小会对速度有很大影响
image

1赞

你好, wey
结果不是很预期…
image


1赞

看起来因为yangmeng这个importor的运行环境太豪华了,以至于,50到88个cocurrency 在这两种 batchsize的时候都达到了 storage/server端的最大处理能力(还有网络传输)了,所以importor这边已经没有优化余地了,您觉得呢?
:+1:t2:,多谢你花了这么多时间做实验,然后还share结果过来。

客气了, 我这刚好也需要多份数据后续测删除, 机器这块的,我确定只用了一点点, 应该是目前默认配置下的nebula的最大import的能力了…
image
image
image

2赞

一般不太会的。
1个nebula importer的能力,不足以压满多个server的。

1赞

这样呀,好的好的,谢谢吴老师!那就是那几个组合下都达到了importor的输出极限?

importer我们也没有特别调过最优。因为单机导入一般数据量也不会太大,基本上改下并发和batch就够了。而且一个client压一个集群,硬件本身就很难压满的。

想大批量写入还是用spark吧

2赞

你好, wey, 能麻烦指导一下这个问题吗? 具体是什么timeout呢?’

hello, wey
咨询你下, 这个storage 在线扩容的时候, BALANCE DATA, BALANCE LEADER; 这些命令的同时, 数据库还能对外提供服务吗?? 在线扩容其实我已经测了, 但是这一点忘了给 :sweat_smile:
image

请求应该会失败,报leader change等,重试通常可以恢复。

1赞

啊, :joy:, 感谢wu老师, 我还是试试吧, 有结果了给你share :+1:

1赞

:+1: :+1: :+1: 你的结果非常正确, 那我理解这也是BUG, 通过重试可以成功…

见过N多人掉这个坑了。。。。

虽然:known issue和faq都写过。。。。

我其实没理解您这句话的意思…

此数据集 26 亿实体、177 亿关系,估计平均每个节点的度为个位数,关系比较稀疏,而节点度的大小对查询的效率的影响很大,不知有没有这方面的评测?

1赞

这个除了配置是32核,64g ssd磁盘,集群本身做调优了吗,我用k8s装完集群,用java client测试写500个线程对应500session的tps才2000多。

batchSize来个 1000 呢?

1赞

浙ICP备20010487号