[論文レビュー] System G Distributed Graph Database
System G は、1秒間に100,000本以上のエッジを処理できる高速な挿入処理(100,000+ edges/sec)と並行処理可能な低レイテンシーレベルのクエリを最適化した高性能な分散グラフデータベースである。シャーディングアーキテクチャを採用し、新規のRPCベース通信層、タスクベースのランタイム、および2つの最適化されたエッジ挿入技術(Firehoseおよびクエリマネージャードライブ型挿入)を採用しており、12シャーディングで最大2.0倍のスループット向上を達成。Neo4j や JanusGraph よりもスループットとレイテンシで優れた性能を発揮している。
Motivated by the need to extract knowledge and value from interconnected data, graph analytics on big data is a very active area of research in both industry and academia. To support graph analytics efficiently a large number of in memory graph libraries, graph processing systems and graph databases have emerged. Projects in each of these categories focus on particular aspects such as static versus dynamic graphs, off line versus on line processing, small versus large graphs, etc. While there has been much advance in graph processing in the past decades, there is still a need for a fast graph processing, using a cluster of machines with distributed storage. In this paper, we discuss a novel distributed graph database called System G designed for efficient graph data storage and processing on modern computing architectures. In particular we describe a single node graph database and a runtime and communication layer that allows us to compose a distributed graph database from multiple single node instances. From various industry requirements, we find that fast insertions and large volume concurrent queries are critical parts of the graph databases and we optimize our database for such features. We experimentally show the efficiency of System G for storing data and processing graph queries on state-of-the-art platforms.
研究の動機と目的
- 高ボリュームのリアルタイムトランザクション処理に適した、従来のOLTP指向グラフデータベースにおけるパフォーマンスギャップを解消すること。
- 1秒間に100,000本以上のエッジを高速にインジェストでき、数10万件の並行処理可能な低レイテンシーレベルのクエリをサポートすること。
- パフォーマンスを向上させるためにACIDの整合性を緩和しつつも、高いスループットを維持できる分散グラフデータベースを設計すること。
- 新規のメッセージパッシング技術を用いて、分散エッジ挿入における通信オーバーヘッドを低減すること。
- リレーショナルデータベースからの効率的な移行を可能にするために、高速なバッチロードと複雑なクエリ実行を可能にすること。
提案手法
- 低レイテンシーオペレーションを実現するため、キーバリューストア上に単一ノードのグラフデータベースを構築する。
- 単一ノードのデータベースを複数のマシンにシャーディングすることで分散システムを構成し、それぞれがグラフの一部を管理する。
- 数千件の並行クエリや挿入処理を効率的に処理できるタスクベースのランタイムシステムを実装する。
- シャーディングノードとクエリマネージャー間のデータ移動およびクエリルーティングを調整するため、RPCベースの通信モデルを採用する。
- 最小限のノード間通信で実現できる高スループットのバッチエッジ挿入のための「Firehose」技術を導入する。
- クエリを統合し、ラウンドトリップのレイテンシを削減するとともに、結果の集約処理を実行する「クエリマネージャー」コンponentを設計する。
実験結果
リサーチクエスチョン
- RQ1分散グラフデータベースは、通信オーバーヘッドを最小限に抑えながら、リアルタイムのエッジ挿入処理に高スループットを達成できるか?
- RQ2スケーラブルな分散グラフデータベースにおいて、低レイテンシーや並行処理を実現するためのアーキテクチャパターンは何か?
- RQ3シャーディング数やサーバー数の増加に伴い、分散グラフデータベースのパフォーマンスはどのようにスケーリングするか?
- RQ4OLTPワークロードにおけるグラフデータベースにおいて、整合性とパフォーマンスのトレードオフとして許容可能な範囲は何か?
- RQ5Firehose やクエリマネージャードライブ型挿入といった新規のエッジ挿入技術は、従来の方法に比べてどのようにパフォーマンスを向上させるか?
主な発見
- System G は12シャーディングで単一シャーディングと比較して2.0倍のスループット向上を達成し、エッジ挿入ワークロードにおける強力なスケーラビリティを示した。
- Firehose挿入手法は、約6シャーディングで性能が飽和したが、これはクエリマネージャーでのネットワーク帯域幅の制限によるものであり、レイテンシや処理オーバーヘッドによるものではなかった。
- System G はクエリ実行時間において Neo4j や JanusGraph を上回り、JanusGraph は100,000件のクエリを完了するのに数時間かかっており、完全なテストが非現実的であった。
- 24コアのマシンでSMTを有効にした環境では、1サーバーあたり6シャーディングを超えると、過剰なスレッドスケジューリングとコンテキストスイッチングによりパフォーマンス劣化が観察された。
- 高ボリュームの挿入処理時、ネットワークレイテンシがタイミング分解の主因となり、性能が飽和した状態では90%以上の時間が通信に費やされていた。
- クエリマネージャーはクエリを統合し、分散実行を可能にすることでラウンドトリップ通信を削減し、複雑なネIGHBORHOOD検索において応答時間を顕著に改善した。
より良い研究を、今すぐ始めましょう
論文の読解から最終レビューまで、研究時間を劇的に削減しましょう。
クレジットカード登録不要
このレビューはAIが作成し、人間の編集者が確認しました。