图分析系统基准测试报告2/17作为世界上第一个原生、实时和大规模并行处理(MPP)的图数据库,TigerGraph系统加载、存储和查询数据的速度比其他图数据库快.
单台服务器上,TigerGraph的图遍历和查询响应时间比其他图数据库要快2倍到8000倍.
随着访问层数的增加,TigerGraph的优势会更加明显.
TigerGraph的查询性能与机器的数量几乎是线性增长的.
即使是像PageRank这样需要大量的点到点通信的查询,TigerGraph仍然可以使用8倍的机器数量实现6.
7倍的加速.
TigerGraph与生俱来的并行性使它能够比Neo4j的离线加载数据速度快1.
8至3倍,比其他数据库快12至58倍,即使在使用一台机器时也是如此.
TigerGraph的高数据压缩能力可以将一个大图存储在比其他测试的图数据库少5倍到13倍的磁盘空间中.
这个基准测试研究了TigerGraph、Neo4j、AmazonNeptune、JanusGraph和ArangoDB的数据加载和查询性能.
基准测试包括以下内容:1.
数据加载数据加载时间加载后数据占用的磁盘容量2.
数据查询K步子图的查询响应时间弱联通子图和PageRank的查询响应时间集群上查询响应时间的可扩展性概要3/17本节描述测试的图系统、使用的硬件平台和数据集.
图数据库/分析系统TigerGraphDeveloperEdition2.
1.
4Neo4j3.
4.
4CommunityEditionAmazonNeptune1.
0.
1.
0.
200233.
0JanusGraph0.
2.
1,使用Cassandra作为后端存储ArangoDB3.
3.
13,分别使用MMFiles和RocksDB作为存储引擎11ArangoDB提供两个存储引擎选项:MMFiles(内存映射文件)和RocksDB.
MMFiles适用于主要内存的数据集;RocksDB对更大的数据集更好.
https://www.
arangodb.
com/why-arangodb/comparing-rocksdb-mmfiles-storageengines/硬件平台所有的测试都是在相同的AmazonEC2硬件上运行的,除了Neptune使用了两个顶级强大的数据库型实例.
Table1A-每个数据库的云硬件和操作系统此外,Neptune需要一个客户端机器来提交数据加载作业.
DatabaseEC2MachinevCPUsMemory(GiB)ProvisionedIOPSMaxBandwidth(Gbps)OSTigerGraphr4.
8xlarge23224425,6007Ubuntu14.
04.
5LTSNeo4jr4.
8xlarge3224425,6007Ubuntu14.
04.
5LTSNeptune1db.
r4.
4xlarge16122160,00033.
5AmazonLinuxAMI2018.
03Neptune2db.
r4.
8xlarge32244323,00027AmazonLinuxAMI2018.
03JanusGraphr4.
8xlarge3224425,6007AmazonLinuxAMI2018.
03ArangoDBr4.
8xlarge3224425,6007Ubuntu14.
04LTS基准设置4/17Table1B-Neptune客户端机器数据集该基准测试使用两个数据集,一个是合成的,一个是真实的.
Table2–数据集2对于r4.
8xlarge,我们附加了一个512GB的EBS-optimizedProvisionedIOPSSSD(IO1),为所有的I/O流量提供了50IOPS/GB的流量.
3AmazonNeptuneIOPS的值是从AmazonCloudwatch控制台获取的.
对于每一个图,原始数据都被格式化为一个以单个制表符(tab)分隔的边的列表:顶点没有属性,所以不需要一个单独的顶点列表.
数据加载测试数据加载测试检查了这两个方面:1.
加载耗时和速度2.
加载后数据占用的磁盘容量EC2MachinevCPUsMemory(GiB)OSMaximumBandwidthr4.
xlarge430.
5AmazonLinuxAMI2018.
03850MbpsNameDescriptionandSourceVerticesEdgesgraph500SyntheticKroneckergraphhttp://graph500.
org240万6700万twitterTwitteruser-followerdirectedgraphhttp://an.
kaist.
ac.
kr/traces/WWW2010.
html4160万14.
7亿U1U3U1U4U2U35/17数据加载方法对于每个图数据库,我们选择了最有利的初始数据批量加载方法:Table3–每个数据库的数据加载方法我们发现,一些图数据库要么需要一些前置处理、要么需要一些后处理工作.
我们的数据集只包含边列表,但是其他系统要么必须(Neo4j,Neptune,ArangoDB)在加载边之前加载顶点、要么(JanusGraph)能从加载边之前加载顶点的方式获得益处.
因此,我们编写了一个简单的脚本来生成一个顶点文件,它包含了边列表中所有惟一的顶点id.
Neptune的数据格式要求比其他的要严格.
为了避免在使用JanusGraph时的内存问题,我们将数据文件分割成几个小的数据集,然后按顺序加载它们.
对于Neo4j,用户需要在加载后,额外构建一个索引以获得良好的查询性能.
我们将整个数据加载分为四个阶段,并测量每个阶段的耗时.
顶点文件准备:生成顶点文件的时间.
顶点加载:将顶点加载到图的时间.
边的加载:将边(也许有顶点)加载到图的时间.
索引构建:大多数图数据库在加载期间构建一个主ID索引.
Neo4j要求这是作为一个单独的步骤来完成的.
如果没有索引,查询性能会显著降低.
加载耗时和速度下面的表格显示了两个数据集的总加载耗时和每个数据库的每个阶段耗时.
NameLoadingAPIorMethodTigerGraphGSQL声明加载作业Neo4jneo4j-import(脱机加载器),然后在顶点上构建索引以加快查询速度Neptune将外部文件(存储在S3中的)直接加载到NeptuneDB实例的Neptune加载器JanusGraph使用TinkerPopAPI添加顶点和边的Java程序ArangoDBarangoimp批量导入工具6/17Table4A–graph500的数据加载耗时(单位:秒)Table4B–Twitter数据加载耗时(单位:秒)4ArangoDB.
m的边加载时间为24.
4小时,加载了54%的数据,然后耗尽了内存.
*Neo4j批量加载过程包括加载顶点文件和边文件两个部分,我们记录了批量加载的总耗时.
下面以图方式说明了这些加载耗时.
图1A-graph500数据加载耗时TigerGraphNeo4jNeptune1Neptune2JanusGraphArangoDB.
mArangoDB.
redge56.
037.
31,571.
01,052.
0574.
6599.
6944.
9vertex--45.
030.
043.
911.
544.
5vertexfileprep-54.
493.
293.
254.
454.
454.
4index-7.
99total56.
099.
71,709.
21,175.
2672.
9665.
51,043.
8relative11.
830.
521.
012.
011.
918.
6TigerGraphNeo4jNeptune1Neptune2JanusGraphArangoDB.
mArangoDB.
redge785685422482170012192N/A420137vertex--733503839206272vertexfileprep-1270225922591270-1270index-126total7852081452402446214301N/A21679relative12.
757.
631.
218.
2N/A27.
67/17图1B-Twitter数据加载耗时只有Neo4j的加载时间与TigerGraph的加载时间是可比的(比TigerGraph慢1.
8倍到2.
7倍).
我们使用Neo4j的离线加载方法(不允许并发数据库操作);它的在线加载方法要慢得多5.
除了Neo4j之外,TigerGraph比其他图数据库加载小数据集时快12到31倍,加载大数据集时快18到58倍.
TigerGraph具有最简单的加载过程,不需要前置处理或后处理.
5我们在2017年对Neo4j的离线和在线加载方法进行了基准测试:https://doc.
tigergraph.
com/report/WP_NPGbenchmark_Sep17_web.
pdf加载后数据占用的磁盘容量加载后数据占用的磁盘容量是系统成本和性能的重要考虑因素.
在其他条件相同的情况下,一个紧凑的数据库存储可以在给定的机器上存储更多的数据和拥有更快的访问时间,因为它可以获得更多的缓存和页面命中率.
TigerGraph自动编码和压缩数据,将加载后数据的大小减少到小于原始数据量的一半.
相反,所有其他数据库都放大了输入数据量.
我们在加载后测量了数据库存储数据的大小.
对于Neptune,我们使用Cloudwatch控制台来获得加载后数据的存储量大小.
亚马逊用户指南说他们的系统自动复制6次数据,所以我们把测量到的数据量数字除以6.
8/17Table5–加载数据的存储量(单位:MB)下面的图表比较了图存储量大小,比较基准为原始数据量大小.
图2–加载数据后数据库数据容量比较数据存储量综述原始数据被压缩并存储在TigerGraph数据库中,从而为Graph500数据集节省了50%的存储空间,并为Twitter数据集节省了61%的存储空间.
其他的图数据库创建的图数据量都比原始数据量大,需要比TigerGraph多5倍到13倍的存储空间存储数据.
DatasetRawDataTigerGraphNeo4jNeptuneJanusGraphArangoDBgraph5009674822,3003,8502,7646,657twitter24,3759,50049,00091,14055,296126,970查询性能测试数据检索或查询是任何数据库系统的基本功能之一.
数据分析系统必须能够执行用户应用程序所需的查询类型,并且必须快速执行.
9/17查询性能测试检查了这三个方面:K度顶点计数查询的查询响应时间弱联通子图和PageRank(全图查询)的查询响应时间查询响应时间的可扩展性K度查询K度路径顶点计数查询,它计算从起始顶点有长度为K的路径的顶点的总计数,这是一个很好的图遍历性能的度量.
对于每个数据集,我们测量下列查询的查询响应时间:计算300个固定随机种子的所有一度的顶点,并将超时设置为3分钟/查询.
计算300个固定随机种子的所有两度的顶点,并将超时设置为3分钟/查询.
计算10个固定随机种子的三度的顶点,并将超时设置为2.
5小时/查询.
计算10个固定随机种子的六度的顶点,并将超时设置为2.
5小时/查询.
"固定随机种子",意思是我们从图中一次性随机选择N个顶点,并将这个列表保存为测试的可重复输入条件.
每条路径查询都从一个顶点开始,并找到所有位于长度为K路径末端的顶点.
N个查询是按顺序运行的.
每个起始顶点都有不同的查询子图大小;我们报告中取平均值.
为了将注意力集中在图遍历和最小化网络输出时间上,我们只输出K度路径查询子图的大小,而不是完整的顶点列表.
我们在参与测试的图数据库中,对所有测试查询结果进行交叉验证.
