Nebula 与 Neo4j、ArangoDB 等图数据库的 Benchmark

Nebula 与 Neo4j、ArangoDB 等图数据库的 Benchmark

本文出品自:苏宁智能监控与运维产研中心算法 Lab

苏宁线上的电商系统以及基础设施随着时间推移日益复杂,随着大规模的异常检测的落地以及结合传统基于规则的告警,我们迫切需要有效的告警收敛机制,而如何发现根告警(Root Alarm)变得更为紧迫。

通过构建运维和告警双重知识图谱能够有效解决这样的挑战。而知识图谱的核心是图,选择分布式图数据库是一项非常严谨的工作,我们选择了业界比较流行的两个图数据库与 Nebula 进行了对比和评测。

1. 评测对象

  • Nebula Graph:版本 1.1

  • Neo4j: Neo4j 是目前业界广泛使用的图数据库,有社区版本和商用版本,我们使用社区版本,社区版本不支持集群。

  • ArangoDB: ArangoDB 是一个开源的多模态数据库,可用来存储文档,图等类型的数据。支持集群,具有良好的读写性能。

2. 测试数据集

测试数据使用的是 GitHub - weinberger/nosql-tests: NoSQL benchmark tests for documents and graphs 中的测试数据。

数据总共包含 1632803 点,30622564 边。其中,Onehop 查询平均一个节点有 18 个邻居;Twohop 查询平均一个节点有 800 个邻居。

3. 测试环境

机器配置:

  • CPU:16c
  • 内存:128G
  • 磁盘:2400G

Neo4j 只测试单机,Nebula 和 ArangoDB 分别测试了单机和集群:

  • 单机:1台
  • 集群:3台

版本信息:

  • CentOS 7.3
  • Nebula 1.1.0
  • ArangoDB 3.7.2
  • Neo4j 3.3.1

4. Benchmark结果

4.1 批量数据导入和 onehop、twohop 查询

20

以 ArangoDB 单机测试结果作为基准 1,对比结果如下图所示:

查询场景评测如下:

22

从查询语法的视角考察,AQL,nGQL 和 Cypher 都比较简练。但是,从可读性以及语法的学习复杂性考察,nGQL 类似 SQL,更加符合大家的使用习惯。

4.2 其他评测场景

以 ArangoDB 单机测试结果作为基准 1,对比结果如下图所示:

拆分再细看一下每个场景的对比,

5. 结论

通过上述测试结果可知,nebula 的批量导入速度快于 ArangoDB,但 Nebula 的 onehop 和 twohop 查询均慢于 ArangoDB 和 Neo4j,关于这一点,可以进一步讨论, 但是考虑到 Neo4j 社区版本不支持集群,ArangoDB 批量导入性能并不理想,而且处于半开源状态, 社区版的 SmartGraph 等核心能力并不开源,最后我们选择 Nebula Graph,当然, Nebula Graph 能够比肩 Neo4j 等分布式图数据库,这本身就是国人的骄傲!后续生产场景下的实践我们也会陆续和社区分享,一起促进 Nebula Graph 生态的发展。

作者:

  • 汤泳 苏宁智能监控与运维产研中心总监
  • 胡创奇 苏宁智能监控与运维产研中心算法 Lab
  • 夏丹 苏宁智能监控与运维产研中心算法 Lab
  • 张波 苏宁智能监控与运维产研中心算法 Lab
5 个赞

数据量似乎不大,能看下硬盘上的量是不是足够放在内存里面?
另外这个硬盘看上去像是一个HDD?

还有,我看ArangoDB的2hop还是很快的(4ms),我记得它是有个edge index,是因为这个index都cache了的关系吗?

嗯,3000万量不大, 后续准备将调用链数据量(700w/s)的接入进行进一步评测, 构建拓扑关系。

目前评测用的是普通硬盘没有使用SSD, 调用链数据场景下考虑要切到SSD做评测, 确实长尾影响要考虑。

硬盘的量是不是足够放到内存里面
有文档参考一下吗

ArangoDB的edge index我进一步确认一下。

索引类型非常丰富, 边集合自动有排序的索引。所以2跳或者说边查询场景非常快!

我们调整到128的1/3,重新测一下, 默认的确实没有修改。

可以du看下硬盘上数据量,再对比下内存。我猜测是数据量不大,cache的效果能比较好。
一跳10ms,二跳20ms,差不多符合机械盘随机读的耗时。

调整完rocksdb_block_cache后, Nebula一跳和二跳与调整前相比,基本没有变化, 但是在预期中(二跳20ms多一点),ArangoDB 的边索引对于结果性能提升起了很大作用。

这个设置后续在大体量下保留, 结果再次会重新测试。

rocksdb_block_cache只是一个LRU 的data cache,大多数数据还是在HDD上,缓存不了什么图拓扑结构。
ArangdoDB的edge index是边索引,常驻可以缓存图拓扑。
在这个小数据量下,大体还是符合预期。以后可以试试大数据量的场景。

请问一下,nebula有没有哪个配置可以把图拓扑结构放到缓存中? :grinning:

没有。。
设计时候是这么考虑的:假设图是很大的(所以不能只靠内存),图遍历过程中需要有剪枝过滤(因此需要有属性,而属性比较大)。
当然,其实也可以做一些优化:比如storage的key value可以分离成wisckey,这样key部分就很小容易常驻内存,这样接近把图拓扑放内存。
但是因为存储计算分离的架构,图拓扑就算缓存了,也是切片放在多台机器上,没法grappd长期缓存。
不过因为假设常见场景是前者,所以后者这种优化改动没有做。

最后,在小数据场景下,我感觉test case都跑一遍之后,数据也应该在cache里面了,不应该在HDD了,所以2跳20ms就有点怪。

除了我们后续切到大体量数据, Nebula或者说业界有没有公开的benchmark海量数据集,可以作为基准来评测一下。

nebula-bench这个repo是用LDBC的,有挺多人已经跑过了。
不过如果你们有自己的内部数据集这个意义更大

2 个赞

我这边对arangodb分布式场景(3台dbserver)进行数据导入发现,3台机器的数据落盘大小非常不均匀,有1台机器会占据90%的数据。
不知道这个情况那边测试时有观察过吗?

有没有2.0版本的对比呀