Galaxybase开发者版本图数据库基准测试

包括Galaxybase-D、TigerGraph、Neo4j、HugeGraph和Nebula

测试报告摘要
Galaxybase是国内成熟的超大规模分布式并行原生图平台产品，具有完全自主知识产权，拥有运算快、高扩展、高集成和轻部署的技术优势。

Galaxybase Developer(简称Galaxybase-D)是Galaxybase开发者版，为图分析、计算及应用领域的开发者提供免费的单机图数据库服务。

本次基准测试，我们选取了TigerGraph、Neo4j、HugeGraph和Nebula这四款比较流行的图数据库与Galaxybase-D作横向对比。测试内容包括：

数据加载

1.数据加载时间

2.数据落盘大小

查询性能

1.K跳邻居查询测试

2.短路径查询测试

3.全图算法查询测试

测试结果概览
Galaxybase-D数据压缩性能，数据导入后磁盘占用空间约为Neo4j和Nebula的1/2、HugeGraph的1/8。

K跳邻居的查询速度，Galaxybase-D比其他图数据库快2到1000倍。

短路径的查询速度，Galaxybase-D比其他图数据库快6倍以上。

全图算法支持及性能上，Galaxybase-D全面领先。其中，PageRank算法较其他数据库[ HugeGraph和Nebula目前版本数据库不直接支持所测算法，故无法进行性能比较。]快-3到6倍；弱连通子图算法快2到20倍；标签传播算法快6到10倍。

1. 基准测试设置
本节描述测试的图数据库系统、使用的硬件平台和数据集。

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

Galaxybase Developer 3.0.2

TigerGraph Developer 2.5.3

Neo4j Community 3.5.19

HugeGraph 0.10.4

Nebula 1.0.1

1.2 硬件环境

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

服务器配置
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-D 使用 galaxybase-console-buildgraph 工具导入
TigerGraph GSQL声明加载作业
Neo4j 使用neo4j-admin import离线导入
HugeGraph 使用HugeGraph-Loader工具导入
Nebula 使用Nebula Importer工具导入
2.2 数据加载时间

2.3 数据落盘大小
注：

1.在导入Twitter数据集时，Nebula占用磁盘的峰值达到了134G。

2.在导入完成后，Nebula会在某种情况下自动压缩落盘数据，压缩过程 较长，Graph 500数据集需要100秒， Twitter 2010数据集需要45分钟，在压缩过程中占据较高的IO，影响性能，为了避免这种情况，我们关闭了它的自动压缩。

2.3.1 落盘大小测试方法说明

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

测试项 落盘目录
Galaxybase-D ${galaxybase-home}/db/store/ ${graphIndex}
TigerGraph ~/tigergraph/gstore
Neo4j ${neo4j-home}/data/datebase/ ${graph-name}
HugeGraph ${hugegraph-home}/rocksdb-data
Nebula /usr/local/nebula/data/storage
2.4 数据加载小结

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

Galaxybase-D和Neo4j相比，导入时间长，落盘空间小。原因在于Galaxybase-D为了加快查询，在加载时就对边进行了特殊处理，同时进行了压缩，所以加载时间长，但落盘空间小。

Galaxybase-D和HugeGraph相比，导入时间短，落盘空间小，导入时间约为HugeGraph的35%至40%，落盘大小约为HugeGraph的10%至20%。

Galaxybase-D和Nebula相比，导入时间短，落盘空间小，导入时间约为Nebula的25%至30%，在该导入时间内落盘大小为Nebula的10%至50%。

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

K跳邻居查询测试

短路径查询测试

全图算法查询测试

注：为了查询结果的稳定性，对于每个测试项，我们将执行三次，次测试用来排除冷启动带来的干扰，取第二、三次耗时的平均值作为结果，同时记录查询超时或报错的比例。

3.1 K跳邻居查询测试

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

3.1.1 查询方法

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

对于Galaxybase-D，具体使用的查询接口是JavaAPI中的bfsMaster接口；对于TigerGraph，通过编写GSQL实现查询逻辑。类似的，Neo4j使用对应的Cypher语句，HugeGraph使用对应的Gremlin语句，Nebula使用对应的nGQL语句。

注：

1.为了方便不同benchmark之间的比较，本次测试样本集取自TigerGraph的benchmark项目。

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

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

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

3.1.2 测试结果

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

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

  
在Graph 500数据集下
  
Neo4j在五跳查询时，出现超时或报错的比例为80%；六跳查询时，出现超时或报错的比例为90%。

Nebula在三跳查询时，出现超时或报错的比例为70%，四跳查询时，出现超时或报错的比例为90%；在五跳、六跳查询时，所有样本均超时或报错。

在Twitter 2010数据集下

Neo4j在三跳查询时，出现超时或报错的比例为70%；在四跳、五跳、六跳查询时，所有样本均超时或报错。

HugeGraph在一跳查询时，出现超时或报错的比例为6%；在二跳查询时，出现超时或报错的比例为44%；在三跳、四跳、五跳、六跳查询时，所有样本均超时或报错。

Nebula在二跳查询时，出现超时或报错的比例为88%；在三跳、四跳、五跳、六跳查询时，所有样本均超时或报错。

一跳查询
  
二跳查询
  

3.1.3 结论

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

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

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

3.2 短路径查询测试

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

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

  
3.2.2 结论

Galaxybase-D的短路径查询响应速度比TigerGraph、Neo4j、HugeGraph和Nebula均快了一个数量级以上。

注：

Graph 500数据集下，Nebula的短路径算法出现超时或报错的比例为8%。

Twitter 2010数据集下，Nebula的短路径算法出现超时或报错的比例为85%。

3.3 全图算法查询测试

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

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

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

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

3.3.1 测试结果

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

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

1.timeout：3小时未跑出结果。

2.unsupported：未从公开资料中找到在数据库上直接实现的对应方法。

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

3.3.2 结论

Galaxybase-D的算法支撑在所测图数据库中优。

Galaxybase-D的PageRank比TigerGraph及Neo4j快-3到6倍。

Galaxybase-D的弱连通子图比TigerGraph及Neo4j快2到30倍。

Galaxybase-D的标签传播算法比TigerGraph及Neo4j快6到17倍。

3.4 查询性能小结

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

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

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

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

关于Galaxybase
Galaxybase作为国内成熟、通用的商业化分布式原生并行图数据平台产品，解决了大规模关联数据高效存储、查询、计算的难题，高效实现海量数据的实时深链查询、分析，为企业打通数据孤岛、建立以推理为基础的人工智能，提供了从数据迁移、数据建模、数据存储、数据查询、数据运算到数据分析的一站式解决方案。

产品特色：

无编程可视化图模型构建、分析视窗，让客户可以专注在业务逻辑的实现上

完备的图算法支持，开箱即用，降低开发成本、加速AI价值转化

全面的图查询语言支持、丰富的开发接口，更加通用、可扩展

优异的可封装图服务能力

-END-
————————————————
版权声明：本文为CSDN博主「创邻科技」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_41604676/article/details/115723903