Galaxybase企业版图数据库基准测试

Galaxybase企业版图数据库基准测试
包括Galaxybase、TigerGraph、Nebula Graph、HugeGraph、JanusGraph和ArangoDB

测试报告摘要

本次基准测试，旨在测试分布式图数据库之间的性能差异，我们选取了TigerGraph(下表简称Tiger)、Nebula Graph（下表简称Nebula）、HugeGraph（下表简称Huge）、JanusGraph（下表简称Janus）和ArangoDB这五款比较流行的分布式图数据库与Galaxybase企业集群版作横向对比。（Neo4j的集群版提供的是多机只读副本，不具备分片存储和分布式计算的能力，因此本次测试不纳入比较。）测试内容包括：

数据加载

1.数据加载时间

2.数据落盘大小

查询性能

1.K跳邻居查询测试

2.最短路径查询测试

3.全图算法查询测试

1.基准测试设置

1.1 测试的图数据库及系统版本

Galaxybase 3.1.0

TigerGraph 3.1.0

Nebula Graph 2.0.0

HugeGraph 0.10.4

JanusGraph 0.5.3

ArangoDB 3.7.6

1.2 硬件环境

本次测试在3个节点的多机环境下，对所有图数据库系统都采用相同配置的服务器进行测试，详细配置信息如下：

	服务器配置
CPU参数	12核心3.5GHz
内存	128G DDR4
网络宽带	千兆
硬盘	5.5T机械硬盘

1.3 软件环境

操作系统：Ubuntu 16.04.1 LTS(kernel版本：4.15.0-72-generic)

Java版本：Java SE 8 Update 201 (build 1.8.0_201-b09)

Docker版本：Docker version 17.06.2

1.4 测试数据集

注：以上数据描述为原始数据下载链接，实际操作时，数据会分成点文件和边文件进行加载。

2. 数据加载测试

数据加载测试主要检测以下两个方面：

数据加载时间

数据落盘大小

2.1 加载方法

对于各个图数据库产品，我们都选择了对该图数据库产品自身最有利的批量加载数据方法，具体加载方法如下：

测试项	加载时使用的API或方法
Galaxybase	使用 galaxybase-console-buildgraph 工具导入
TigerGraph	GSQL声明加载作业
Nebula Graph	使用Nebula Graph Importer工具导入
HugeGraph	使用HugeGraph-Loader工具导入
JanusGraph	使用TinkerPop API 添加顶点和边的Java程序
ArangoDB	使用arangoimport脚本导入

2.2 数据加载时间及落盘大小
注：Nebula Graph数据加载有两种模式:
1.开启Compact功能，
（1）优点：具有自动压缩功能，使数据落盘更小，优化数据存储结构，便于后续算法执行。
（2）缺点：Compact过程会发生长时间的硬盘IO，强制占用大量资源；

2.关闭Compact功能，
（1）优点：数据导入速度快。
（2）缺点：数据落盘大，且后续算法执行缓慢，报错率高。由于开启Compact功能后，数据压缩时间不定，无法客观记录，此处记录的是未开启Compact模式下数据的导入时间与落盘大小。数据导入完成后，在后台开启Compact功能，数据落盘最终稳定在Graph 500数据集1.9 G，Twitter-2010数据集39 G。

2.2.1 落盘大小测试方法说明
本次测试的图数据库系统都有固定的落盘路径，我们通过du -sh命令测量落盘目录的大小，从而获得落盘数据。各个图数据库我们测试的落盘目录如下：

测试项	落盘目录
Galaxybase	${galaxybase-home}/db/store/ ${graphIndex}
TigerGraph	~/tigergraph/gstore
Nebula Graph	/usr/local/nebula/data/storage/nebula
HugeGraph	hdfs://hbase/data/${graph-name}
JanusGraph	${cassandra-home}/data/data/ ${graph-name}
ArangoDB	启动时 --starter.data-dir参数指定的目录

2.3 数据加载小结

Galaxybase与TigerGraph相比，导入时间长，落盘空间大。原因在于TigerGraph两点之间只支持一条同类型的边，适用场景有限；而Galaxybase对两点之间同类型的边的数量不做限制，且为了方便对边的精确查询，对每条边设置了边id，增加了时间和落盘的开销。Graph 500的点边比为1：27，Twitter-2010的点边比为1:35，在无属性、仅存点边结构的图上，边id所占落盘空间比例大。

和Galaxybase相比，Nebula Graph导入速度不稳定，导入速度会随着时间的推移有所下降，在处理如Twitter-2010这类规模大的数据集时，导入时间明显增大，落盘大小压缩后依然整体大于Galaxybase。

Galaxybase与HugeGraph、JanusGraph、ArangoDB三款图数据库相比，导入时间更短，落盘空间更小。

3. 查询性能测试

图数据库的查询性能测试检测了以下三个方面：

K跳邻居查询测试

最短路径查询测试

全图算法查询测试

3.1 K跳邻居查询测试

K跳邻居（k-hop neighbor）查询，是在一个未加权的有向图中，定义点v的k跳邻居为：从v开始以不超过k跳可达（即经过k条或者更少的边）的所有点的集合，该查询为检验图遍历性能的经典方法。

3.1.1 查询方法

对每个数据集，选取100个样本，统计其N跳扩展所遍历到邻居点的数量，记录平均时间进行对比。分别测试N=1、2、3、4、5、6的情况。N为1、2时，设置超时时间为3分钟/查询，3跳及以上时，设置超时时间为1小时/查询。

对于Galaxybase，具体使用的查询接口是JavaAPI中的bfsMaster接口；对于TigerGraph，通过编写GSQL实现分布式查询逻辑。类似，HugeGraph使用对应的Gremlin语句，Nebula Graph使用对应的nGQL语句，ArangoDB使用对应的AQL语句，JanusGraph使用对应的Gremlin语句。

注：

1.在样本的选择上，会遇到两个问题：（1）如果样本点出度太小，那么就不能很好地体现图遍历性能；（2）如果样本点间出度相差过大，那么查询的耗时相差也会很大，统计出的平均值的指导意义就会下降。为了规避这两个问题，对每个数据集，我们从出度为1000的点中随机选取了100个作为样本。

2.为了将测试重心集中在图遍历上，避开结果传输的影响，我们只查询K跳邻居的数量，而不是返回完整的邻居点集合。

3.为了查询结果的严谨性，我们在参与测试的图数据库中，对查询结果进行了交叉验证，确保不同数据库的查询结果一致。

4.由于HugeGraph、JanusGraph、ArangoDB 3-6跳查询耗时过长，且频频超时，为了降低测试的时间成本，我们将测试样本数量减少到10个，选取标准为从100个样本中选前10个。

3.1.2 测试结果

基于Graph 500数据集，各图数据库执行不同跳邻居查询的耗时结果如下:

基于Twitter-2010数据集，各图数据库执行不同跳邻居查询的耗时结果如下:

在Graph 500数据集下

1.ArangoDB在三跳查询时，查询失败（超时或报错）的比例为70%，四跳及以上查询时，所有样本均查询失败。

2.由于Graph 500数据集存在两点间多边的情况，边的终止点可能会重复，所以在一跳查询时，所得平均邻居数小于1000。

在Twitter-2010数据集下

1.Nebula Graph在三跳查询时，查询失败（超时或报错）的比例为90%，四跳及以上查询时，所有样本均查询失败。

2.HugeGraph在二跳及以上查询时，所有样本均查询失败。

3.JanusGraph在二跳查询时，查询失败（超时或报错）的比例为13%，在三跳及以上查询时，所以样本均查询失败。

4.ArangoDB在二跳查询时，查询失败（超时或报错）的比例为90%，在三跳及以上查询时，所有样本均查询失败。

一跳查询

二跳查询

注：

1.上述柱状图只展示一、二跳查询结果，三至六跳查询结果数量级差距过大，不便展示以柱状图展示。

2.柱状图中，空白项为该图数据库产品不直接支持该算法或所有样本均超时/报错。

3.1.3 结论

以上结果表明，相比所测其他图数据库，Galaxybase的K跳邻居查询性能最好，而且数据规模越大，查询深度越深，优势越明显。

对大部分所测图数据库来说，3跳以上的邻居查询就开始有挑战性了，尤其是数据规模比较大时，会频繁出现报错或者超时现象。除TigerGraph以外，大部分所测图数据库在Twitter-2010数据规模下，3跳及以上就全部查询失败（超时或报错），但Galaxybase在两个数据集下，6跳遍历到的平均邻居数达到3500万量级时，平均查询响应时间依然在15秒左右。

Galaxybase在K跳邻居查询上展现的优异性能，得益于它使用了原生图存储的方式，同时对图遍历算法进行了深度优化。

由于调用TigerGraph的分布式算法，1跳查询时候，主要耗时较多在服务器之间的通信上，若使用单机版TigerGraph，耗时将下降较多。

3.2 最短路径查询测试

最短路径是最常用的图算法之一。我们准备了100组样本，路径长度为1-5的样本各占20%，设置超时时间为5分钟。

3.2.1 测试结果

基于相同数据集，各图数据库执行最短路径查询的耗时情况如下:

注：

1.在Graph 500数据集下，JanusGraph最短路径算法超时比例为62%。

2.在Twitter-2010数据集下，Nebula Graph最短路径算法报错比例为30%；JanusGraph最短路径算法超时比例为86%。

3.2.2 结论

Galaxybase的最短路径查询性能，与其他数据库相比，有数量级的优势且运行稳定不易出错。

3.3 全图算法查询测试

全图算法的运算需要遍历整个图，且计算结果描述的是整体的图特征。本次测试，我们取全图算法的三个例子进行测评比较：PageRank、弱连通子图和标签传播算法。

注：

1.PageRank 算法是一种迭代算法，常用来衡量每个点相对于其它点的影响程度。每次迭代中算法都会遍历每条边，并为每个点计算一个得分值。经过多次迭代后，这些分值将趋于稳定。本次测试我们设置迭代次数为10。

2.弱联通子图（Weakly Connected Components）算法主要用于分析图结构，它描述图中所有可以互相连通的点、以及点之间的边的集合（如果是有向边则忽略其方向）。该算法要求遍历图中每个点和每条边，并会在图中找到且标记所有的弱联通子图。

3.标签传播算法（Label Propagation Algorithm）是最快的社区检测算法。它可以依据图结构划分不同的社区。

3.3.1 测试结果

基于相同数据集，各数据库执行常用图算法的耗时情况如下:

注：

1.unsupported：无法在数据库上直接调用对应算法。

2.ArangoDBException：在根据官方文档调用ArangoDB算法时收到异常响应（具体的异常信息可从本项目的GitHub上找到）。

测试结果性能对比柱状图如下：

3.3.2 结论

Galaxybase和TigerGraph作为两款商业化图数据库，在算法支撑度上相较其他所测开源数据库更加完善。

Galaxybase的PageRank算法略优于TigerGraph。

Galaxybase的弱连通子图算法比TigerGraph快4到5倍。

Galaxybase的标签传播算法比TigerGraph快2到3倍。

3.4 查询性能小结

Galaxybase在K跳邻居查询测试上是领先其他产品的，并且扩展度数越深，邻居数越多，Galaxybase的优势越明显。

Galaxybase在全图算法上，支持的类型更多，并且优化的更好，直接体现就是执行速度更快。

4. 其他

所有重复本基准测试所需的文件（数据集、查询语句、脚本、样本参数、结果文件）都可以在GitHub上找到：

如果您对本测试有疑问或者反馈，请与我们联系：info@chuanglintech.com

-END-

想了解更多图数据库相关知识请在微信搜索【创邻科技】公众号！