[論文レビュー] 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 Social Network Benchmark (SNB) を用いて、オンプレミスおよびクラウドアーキテクチャ上でのスケールファクター SF-1 から SF-1000 までをカバーする、Neo4j と TigerGraph の包括的かつ再現可能なベンチマークを提示している。TigerGraph は、特に複雑なクエリおよびビジネスインテリジェンスワークロードにおいて、大多数のクエリで 2 以上のオーダーの差を示し、Neo4j よりも優れた性能を発揮している。SF-1000 まで優れたスケーラビリティを示し、ストレージは 4 倍削減されている。一方、Neo4j は SF-100 まででデータロードが速く、インデックス構築が遅いため、SF-1000 では総合的なロード時間が 2 倍遅くなる。

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) で、LDBC SNB の全 46 クエリを実装し、ベンダーの支援による最適化を実施。
• オンプレミスおよび 2 つのクラウド環境を含む、合計 3 つのコンピューティングアーキテクチャ上で、4 つのスケールファクター (SF-1, SF-10, SF-100, SF-1000) で全クエリを実行。
• 両システムのクエリ実行時間、バルクロード時間、ストレージサイズ（生データおよびインデックス済み）を測定。
• 公式 LDBC SNB データジェネレータを用いて、現実的なスキーマとデータ分布を持つ合成されたソーシャルネットワークデータを生成。
• スケーラブルでないパフォーマンスを特定するため、タイムアウトしきり（18,000 秒）を適用。
• 再現性を確保するため、すべてのクエリスクリプト、設定ファイル、ベンチマークコードを公開。

実験結果

リサーチクエスチョン

• RQ1 Neo4j と TigerGraph は、スケールファクター SF-1 から SF-1000 まで、インタラクティブ短時間、インタラクティブ複雑、ビジネスインテリジェンスワークロードの全範囲でどのように性能を発揮するか？
• RQ2 クエリ実行時間、バルクロード、ストレージ効率の観点から、Neo4j と TigerGraph の相対的なパフォーマンスはどの程度か？
• RQ3 両システムは大規模データ（SF-1000）までどの程度スケーリングできるか？また、パフォーマンスのボトルネックは何か？
• RQ4 ベンダー最適化されたクエリプランの導入が、ベンチマークの結果および再現性にどのように影響するか？
• RQ5 ネイティブグラフデータベースにおいて、クエリパフォーマンス、データロード速度、ストレージ容量の間にはどのようなトレードオフがあるか？

主な発見

• TigerGraph は 368 のベンチマーク設定のうち 96.5% で Neo4j を上回り、95% 以上のワークロードで優れたパフォーマンスを発揮。
• 特定のインタラクティブ複雑およびビジネスインテリジェンスクエリでは、TigerGraph が 100X 以上高速な実行を達成し、スケールファクターが大きくなるほど性能差が拡大。
• SF-1000 までスケーリングに成功したのは TigerGraph のみ。Neo4j は 25 個のビジネスインテリジェンスクエリのうち 13 個が 18,000 秒のタイムアウト内で完了しなかった。
• TigerGraph は Neo4j よりも生ストレージで 3 倍、インデックスストレージで 4 倍少ない容量を必要とし、元のデータを 2 倍圧縮。
• Neo4j は生データのバルクロードが速い（SF-1 で最大 3 倍速いが、インデックス構築が非スケーラブルなため、SF-1000 では総合ロード時間が 2 倍遅くなる。
• よりコンactな構文を採用しているにもかかわらず、Neo4j のクエリ実行はほぼすべてのワークロードで TigerGraph に劣っており、クエリ処理におけるアーキテクチャ的優位性が示唆される。