並列クエリオプティマイザ
続いてGreenplumDB が実際にクエリの並列処理を行う時の肝となるクエリ実行プランについて解説します。
コストベース最適化アルゴリズムによるクエリ実行プランの決定
GreenplumDBでは実行プランの作成にコストベースの最適化アルゴリズムを採用しています。コストベースとは、あらかじめデータベース内部に蓄積されたデータ配置に関する統計情報をもとに、クライアントからのクエリを受け付けた際に、内部で幾つか候補となるクエリ実行プランを作成し、その中で最も効率の良い（実行コストの低い）クエリ実行プランを実行するという方式です。このようなクエリ実行プランの作成は全てマスターサーバ上で行われ、作成が終わった時点でマスターサーバからセグメントサーバへクエリ実行プランが転送され、クエリ処理の実行が指示されます。
「モーション」操作: ギャザー、リディストリビュート、ブロードキャスト
GreenplumDBでは、クエリ実行プランは、各セグメントインスタンスが並列で処理できるクエリ実行プランのサブセットに分けられ、このサブセットは「スライス」と呼ばれています。スライスはさらに小さな単位「ノード」に分けられます。ノードの種類には、テーブルのシーケンシャルスキャンやインデクススキャン、ハッシュ集約と言った一般のデータベースが行う処理に加え、セグメントサーバ同士やセグメントサーバとマスターサーバ間でネットワークインタコネクトを介してデータの送受信を行う処理があり、これらの送受信の処理は「モーション」と名付けられています。
モーションには、３種類のデータ送受信の方式があります。ギャザーモーションはセグメントサーバからマスターサーバへの転送で、セグメントサーバでの処理が全て終わった後、最後にマスターサーバへ結果を渡す時に行われる処理です。リディストリビュートモーションとブロードキャストモーションは、セグメントサーバ同士でデータの送受信を行う時に行われる処理です。リディストリビュートモーションはテーブルを特定のハッシュキーを使用してセグメントサーバ間にハッシュ分散し、ブロードキャストモーションではテーブルの全レコードを各セグメントサーバ上に転送します。どちらを採用するかは、テーブルのレコード数やその後の処理に応じて並行クエリオプティマイザが判断します。
パラレルデータフローエンジンと標準SQLの対応
クエリ実行に際して、GreenplumDBの各セグメントインスタンスはノード間で依存関係がない場合、複数のノードを同時に処理していきます。例えば、シーケンシャルスキャンをテーブルに対して実施しながら、スキャンされたデータに対してハッシュ結合を行います。またリディストリビュートモーションでデータレコードをセグメントインスタンス間で転送しながら、各セグメントインスタンスはハッシュ集約を行います。このようにノードの処理がすべて完了するのを待たずに、得られたデータレコードを次のノードへと引継いでいきます。この際、各ノードの処理結果のデータレコードはセグメントインスタンスのローカルディスクに保存されることなく、メモリ上で保持されたまま、次のノードへ渡されていきます。このデータレコードがメモリ経由で処理されていく仕組みは「パラレルデータフローエンジン」により実装されています。
なお、ユーザが使用する言語は標準のSQLであり、ANSI SQL92、99、2003、2008 に準拠していれば、モーションやパイプラインを意識したクエリ実行プランの作成は GreenplumDB のマスターサーバが自動的に行います。このためユーザが処理の並列化を意識する必要はありません。
次回は、データのストア方式について解説します。昨今、トランザクション処理に加えてデータ分析や集計処理の高速化に対する要求が高まるにつれ、データのストア方式についての議論も盛んに行われるようになってきています。最近の技術動向に加え、GreenplumDBの持つ柔軟な機能についてご紹介します。
