Star

Nebula Graph v2 写入性能问题

  • nebula 版本:v2.0.0 rc1
  • 部署方式:单机(Client与Graph不在同一台主机)
  • 硬件信息
    • SSD 4TB
    • CPU 32C Intel® Xeon® CPU E5-2620 v4 @ 2.10GHz
    • Memory 128GB
  • 出问题的 Space 的创建方式:
  • 问题的具体描述
    我关注到官方提供的基准性能测试(写入)结果大约在40w ops/sec左右
    而我自己生成了1000000条数据(只包括点),通过goimporter进行导入,其写入性能不符合预期

    上图中的写入性能大约在6-7w ops/sec
    Tag schema大致如下,没有建立index
SHOW CREATE TAG file


这是我的配置文件

这是我的数据

请问下瓶颈可能在哪里?

之前发布的写入性能基准是1.0的

呃,抱歉我没有注意到版本,2.0 有没有一个预估的写入性能基准?
另外我去做go-importer测试的一个原因是,我自己用JavaClient去做insert的性能也并不高,同样的数据大约只有1-2w ops/sec(远低于goimporter),方式大约是单线程batch写入,每次1000条,这个有点低于我的预期,但不知道该如何优化

importer也有batchSize参数, 默认是128, 你要不调大点试试?image

exchange也可以导入数据到nebula, 导入速度更快: 编译 Exchange - Nebula Graph Database 手册

多谢回复,由于业务限制,我其实只能通过JavaClient去做写入,无论是goimporter或者exchange都只能是提供一个nebula storage的写入性能基准

但基于你上面的回复,我是否可以通过以下途径来优化JavaClient的写入性能:

  1. 增加batchSize
  2. 多线程执行,增加concurrency
  3. 写入时自动调整rocksdb参数(例如auto compaction),防止rocksdb成为瓶颈

另外我理解虽然我可以增加concurrency,但是这个concurrency要适配graphd的threads数量,而这个值在默认情况下是等于CPU核数的

不知道我的理解对不对?

数据量不多的话,memfile搞大点就写完了。

检查下partition分布,很有可能不均匀。

请问如何检查partition分布?有资料链接么

show hosts
show partitions
手册有写

我只有一个storage,所以partition全部是在同一台机器上的…

那。。。。benchmark 我记得是 3-5台 server吧。。。
你把memfile调大点,就100万数据。

好的,多谢,我用OwnThink的那个数据集和go-importer做了个测试,一开始的写入性能大概在17w ops/sec(但是会逐渐下降,最终大概在9-10w ops/sec),理论上如果采用多storage,写入的压力会被平均分配到多个节点,性能确实应该会有成倍的增长,这么算起来如果我用3台storage就能达到benchmark中的性能

exchange 是一个基于Spark的分布式程序 如果数据量不是特别大 importer 更方便

浙ICP备20010487号