[論文レビュー] Join Processing for Graph Patterns: An Old Dog with New Tricks

Dung T. Nguyen, Molham Aref+5 more|arXiv (Cornell University)|Mar 13, 2015

Advanced Database Systems and Queries参考文献 15被引用数 6

ひとこと要約

この論文は、グラフパターン照合のための、完全な機能を備えたリレーショナルデータベース管理システム（RDBMS）である LogicBlox において、最悪ケース最適および最悪ケースを超える最適な結合アルゴリズムである LeapFrog TrieJoin (LFTJ) と Minesweeper を評価する。本研究では、これらの現代的な結合アルゴリズムが、サイクル付きおよび非サイクル付きのグラフクエリにおいて、従来のリレーショナルシステムおよび専用のグラフデータベースを上回る性能を発揮することを示しており、グラフエンジンとの性能ギャップを埋めつつ、高水準な SQL インターフェースを維持している。

ABSTRACT

Join optimization has been dominated by Selinger-style, pairwise optimizers for decades. But, Selinger-style algorithms are asymptotically suboptimal for applications in graphic analytics. This suboptimality is one of the reasons that many have advocated supplementing relational engines with specialized graph processing engines. Recently, new join algorithms have been discovered that achieve optimal worst-case run times for any join or even so-called beyond worst-case (or instance optimal) run time guarantees for specialized classes of joins. These new algorithms match or improve on those used in specialized graph-processing systems. This paper asks can these new join algorithms allow relational engines to close the performance gap with graph engines? We examine this question for graph-pattern queries or join queries. We find that classical relational databases like Postgres and MonetDB or newer graph databases/stores like Virtuoso and Neo4j may be orders of magnitude slower than these new approaches compared to a fully featured RDBMS, LogicBlox, using these new ideas. Our results demonstrate that an RDBMS with such new algorithms can perform as well as specialized engines like GraphLab -- while retaining a high-level interface. We hope this adds to the ongoing debate of the role of graph accelerators, new graph systems, and relational systems in modern workloads.

研究の動機と目的

• 現代的で理論的に最適な結合アルゴリズムが、グラフパターン照合において、リレーショナルデータベースと専用のグラフ処理エンジンとの間の性能ギャップを埋めることを調査すること。
• 実世界の RDBMS 環境における、最悪ケース最適（LFTJ）および最悪ケースを超える最適（Minesweeper）結合アルゴリズムの実用的性能を評価すること。
• これらの新しいアルゴリズムが、従来の Selinger スタイルの最適化とグラフ固有のシステムを上回る条件（クエリおよびデータの特性）を特定すること。
• 高度な結合アルゴリズムを用いることで、1つのリレーショナルエンジン内で OLAP とグラフアナリティクスのワークロードを統合する可能性を評価すること。

提案手法

• LogicBlox RDBMS に、最悪ケース最適なマルチウェイ結合アルゴリズムである LeapFrog TrieJoin (LFTJ) の実装と統合。
• LFTJ とは別に、インテリジェントなインデキシングとキャッシュを用いて再計算を最小限に抑える、最悪ケースを超える最適な結合アルゴリズムである Minesweeper の実装。
• ロウストア（PostgreSQL）、カラムストア（MonetDB）、グラフデータベース（Virtuoso、Neo4j）、グラフ処理エンジン（GraphLab、RedShift、System HC）を含む多様なシステムとのベンチマーク比較。
• LiveJournal、Pokec、Orkut などの複数のデータセットを用いた、クリーク、パス、木、およびハイブリッドパターン（例：ラollipop）を含む実世界のグラフワークロードでの評価。
• スモールティングとエッジサブセットスケーリング実験を用いて、データサイズおよび選択性の変動下での性能とスケーラビリティを分析。
• LFTJ と Minesweeper の長所を活かした混合クエリシナリオにおいて有効なハイブリッドアルゴリズムの設計と評価。

実験結果

リサーチクエスチョン

• RQ1 最悪ケース最適および最悪ケースを超える最適な結合アルゴリズムが、完全な機能を備えた RDBMS が、グラフパターン照合において専用のグラフエンジンの性能を模倣または上回ることを可能にするか？
• RQ2 LFTJ および Minesweeper は、非サイクル型とサイクル型の両方のグラフクエリにおいて、従来の Selinger スタイルの最適化とグラフ固有のシステムと比較して、どのように性能を発揮するか？
• RQ3 Minesweeper のキャッシュ機構が、LFTJ よりも顕著な性能向上をもたらすのは、どのようなクエリおよびデータの環境下か？
• RQ4 これらの新しい結合アルゴリズムは、特に低選択性または高再帰性の状況下で、データサイズの増加に伴いどの程度スケーリングするか？
• RQ5 LFTJ と Minesweeper を統合したハイブリッドアルゴリズムが、混合構造のクエリにおいて、両方の個別アルゴリズムを上回る性能を発揮するか？

主な発見

• サイクル付きグラフクエリにおいて、LogicBlox に LFTJ と Minesweeper を組み込んだ場合、PostgreSQL、MonetDB、Virtuoso、Neo4j、GraphLab よりも、桁違いの高速性能を発揮した。
• LFTJ は、3-クリーク や 4-サイクル といったサイクル付きクエリで最速の性能を発揮し、特にデータが密で選択性が高い状況で顕著であった。
• Minesweeper は、1-木 や 2-木 といった非サイクルクエリで優れた性能を発揮し、再計算が多発する低選択性環境下でキャッシュ機構の恩恵を最大限に受けていた。
• パスとクリーク構造を組み合わせたハイブリッドクエリ（例：i-lollipop）では、ハイブリッドアルゴリズムが LFTJ や Minesweeper の両方を上回った。これは、顕著な最適化の余地があることを示唆している。
• 従来のリレーショナルデータベース（PostgreSQL、MonetDB）および Neo4j は、多くのグラフパターンクエリで、小さなデータサブセットですらタイムアウトを起こしており、こうしたワークロードに対して非効率であることが明らかになった。
• スケーリング実験の結果、最適結合アルゴリズムは従来のシステムよりもデータサイズを2桁以上大きく処理でき、LFTJ は Minesweeper よりも1桁大きいグラフを処理可能であった。