Skip to main content
QUICK REVIEW

[论文解读] In-Depth Benchmarking of Graph Database Systems with the Linked Data Benchmark Council (LDBC) Social Network Benchmark (SNB)

Florin Rusu, Zhiyi Huang|arXiv (Cornell University)|Jul 17, 2019
Graph Theory and Algorithms参考文献 12被引用 4
一句话总结

本论文使用LDBC社交网络基准(SNB)对Neo4j和TigerGraph进行了全面且可复现的基准测试,评估了在本地部署和云架构下,从SF-1到SF-1000规模因子的46个查询的性能表现。在大多数查询中,TigerGraph的性能比Neo4j高出两个数量级以上,尤其在复杂查询和业务智能工作负载中表现更优,其存储空间减少4倍,且可扩展至SF-1000,而Neo4j在原始数据加载方面(至SF-10为止)更快,尽管其索引构建速度较慢。

ABSTRACT

In this study, we present the first results of a complete implementation of the LDBC SNB benchmark -- interactive short, interactive complex, and business intelligence -- in two native graph database systems---Neo4j and TigerGraph. In addition to thoroughly evaluating the performance of all of the 46 queries in the benchmark on four scale factors -- SF-1, SF-10, SF-100, and SF-1000 -- and three computing architectures -- on premise and in the cloud -- we also measure the bulk loading time and storage size. Our results show that TigerGraph is consistently outperforming Neo4j on the majority of the queries---by two or more orders of magnitude (100X factor) on certain interactive complex and business intelligence queries. The gap increases with the size of the data since only TigerGraph is able to scale to SF-1000---Neo4j finishes only 12 of the 25 business intelligence queries in reasonable time. Nonetheless, Neo4j is generally faster at bulk loading graph data up to SF-100. A key to our study is the active involvement of the vendors in the tuning of their platforms. In order to encourage reproducibility, we make all the code, scripts, and configuration parameters publicly available online.

研究动机与目标

  • 通过LDBC SNB基准测试,为原生图数据库系统提供完整且可复现的评估。
  • 在SF-1至SF-1000的规模因子下,对比Neo4j和TigerGraph在交互式、复杂及业务智能工作负载中的性能表现。
  • 测量并对比在本地部署和云环境下的批量加载时间、存储效率及查询执行性能。
  • 邀请系统厂商参与查询调优,并通过公开所有代码、脚本和配置文件,确保基准测试的可复现性。
  • 为未来基准测试建立所有46个LDBC SNB查询在Cypher和GSQL中的参考实现。

提出的方法

  • 在Neo4j(Cypher)和TigerGraph(GSQL)中完整实现全部46个LDBC SNB查询,并在厂商指导下进行性能优化。
  • 在三种计算架构(本地部署及两个云环境)上,对四个规模因子(SF-1、SF-10、SF-100、SF-1000)执行所有查询。
  • 测量两个系统的查询执行时间、批量加载时间以及原始和索引存储大小。
  • 使用官方LDBC SNB数据生成器,生成具有真实模式和分布特征的合成社交网络数据。
  • 应用超时阈值(18,000秒)以识别无法扩展的查询性能。
  • 公开所有查询脚本、配置文件和基准测试代码,以确保可复现性。

实验结果

研究问题

  • RQ1在SF-1至SF-1000的多个规模因子下,Neo4j和TigerGraph在LDBC SNB工作负载全谱(交互式短查询、交互式复杂查询、业务智能)中的表现如何?
  • RQ2在查询执行时间、批量加载和存储效率方面,Neo4j和TigerGraph的相对性能如何?
  • RQ3每个系统在大规模数据(SF-1000)下的可扩展性如何?其性能瓶颈是什么?
  • RQ4厂商优化的查询计划的引入如何影响基准测试结果及可复现性?
  • RQ5在原生图数据库中,查询性能、数据加载速度与存储占用之间存在哪些权衡?

主要发现

  • 在368个基准配置中,TigerGraph在96.5%的情况下优于Neo4j,其中超过95%的工作负载表现更优。
  • 在某些交互式复杂查询和业务智能查询中,TigerGraph的执行速度比Neo4j快100倍以上,且在更大规模因子下性能差距进一步扩大。
  • 仅TigerGraph成功扩展至SF-1000;Neo4j在18,000秒超时限制内未能完成25个业务智能查询中的13个。
  • TigerGraph使用的原始存储空间比Neo4j少3倍,索引存储空间少4倍,且将原始数据压缩了2倍。
  • 尽管Neo4j在批量加载原始数据方面更快(在SF-1时快达3倍),但其索引构建过程不可扩展,导致在SF-1000时总加载时间慢2倍。
  • 尽管语法更紧凑,Neo4j的查询执行性能在几乎所有工作负载中仍落后于TigerGraph,表明TigerGraph在查询处理方面具有架构优势。

更好的研究,从现在开始

从阅读论文到最终审阅,大幅缩短您的研究时间。

无需绑定信用卡

本解读由 AI 生成,并经人工编辑审核。