PolarDB:列指向テーブル向けの超並列処理

パーティションキー

パーティションキーは、データを複数のノードに分散配置します。基本原則は、関連するデータを同じノード上に保持し、ローカルでの計算を可能にすることです。

仕組み

第 1 レベルまたは第 2 レベルで HASH または KEY パーティショニングを使用するパーティションテーブルの場合、マルチノード実行は共有なし（share-nothing）アプローチを採用します。各パーティションは単一のノードによって処理されます。

主なメリット

• データキャッシングの改善：各ノードは割り当てられたパーティションのみを処理するため、ローカルメモリキャッシュをより効率的に活用できます。

• クエリパフォーマンスの最適化：JOIN および GROUP BY 操作をパーティションキーに基づいて実行すると、各ノード上でローカルにデータを処理できるため、ノード間のデータ転送が大幅に削減されます。

ベストプラクティス

• コアとなるビジネスキーを使用：最も頻繁に JOIN 句または GROUP BY 句で使用されるカラム（例：order_id や user_id）をパーティションキーとして選択します。

• パーティション数を一致させる：JOIN 操作に関与するテーブルは、HASH/KEY パーティションの数が完全に一致している必要があります。パーティション数が異なると、ローカル計算が不可能になります。

• パーティション数には大きな素数を使用：97 や 199 などの大きな素数をパーティション数として使用してください。これにより、ノード間でデータが均等に分散され、データスキューを防ぐことができます。

ソートキー

ソートキーは、各物理パーティション内のデータを整理します。基本原則は、読み取り時に不要なデータをスキップすることです。RANGE パーティションを使用するか、列指向テーブルにソートキーを追加することで、大量のデータを効率的にフィルタリングできます。

仕組み

列指向ストレージでは、データはストライプ単位で管理されます。ソートキーを設定すると、各ストライプ内のデータが指定されたカラムで物理的にソートされます。クエリ実行時、エンジンは各ストライプヘッダーに含まれる min/max 値などのメタデータを参照し、そのストライプを読み取るかスキップするかを判断します。

主なメリット

• 効率的なデータプルーニング：WHERE 句でソートキーに基づくフィルター条件を指定すると、クエリエンジンはフィルター条件に該当しないデータ範囲を持つストライプ全体をスキップします。これにより、ディスク I/O が削減されます。

ベストプラクティス

• 高頻度フィルター対象カラムを選択：WHERE 句で頻繁に使用されるカラム（特に範囲クエリ（>、<、BETWEEN）や高カーディナリティの等価クエリ）にソートキーを設定します。

• RANGE パーティションと併用：多段階のデータフィルタリングを実現するため、RANGE パーティションとソートキーを組み合わせて使用します。

SQL ステートメントが MPP を使用しているかどうかを確認する方法を教えてください。

SQL ステートメントの EXPLAIN 実行計画を分析することで、MPP を使用しているかどうかを判断できます。重要な指標は、Exchange オペレーターの有無です。

1. ステップ 1：MPP 計画の実行可能性を確認

   まず、オプティマイザーが SQL ステートメントに対して MPP 計画を生成できるかどうかを特定のヒントを使用して検証します。

   方法：SQL ステートメントの先頭に EXPLAIN を追加し、/*+ SET_VAR(imci_plan_use_mpp=forced) */ ヒントを挿入します。これにより、オプティマイザーは強制的に MPP 実行計画を生成します。

   例

   EXPLAIN SELECT /*+ SET_VAR(imci_plan_use_mpp=forced) */ COUNT(*) FROM nation;

   結果：実行計画に Exchange オペレーターが含まれている場合、その SQL ステートメントはマルチノード並列実行を利用可能です。

2. ステップ 2：実際の実行計画を確認

   実行可能性を確認した後、ヒントなしで元の SQL ステートメントに対してオプティマイザーが実際に MPP モードを選択しているかどうかを確認します。

   方法：元の SQL ステートメントに対して EXPLAIN を実行します。

   例

   EXPLAIN SELECT COUNT(*) FROM nation;

   結果：

   • 実行計画に Exchange オペレーターが含まれている場合、オプティマイザーはそのクエリに対してマルチノード並列実行を有効にしています。

   • 実行計画に Exchange オペレーターが含まれていない場合、以下のいずれかが原因である可能性があります。

     • クエリがシンプルすぎる、または対象データ量が少なすぎるため、オプティマイザーがシングルノード実行の方が高速だと判断しています。

     • SQL 構文やテーブル構造（例：パーティションキーの設定）により、MPP の使用が制限されています。ステップ 1 を参考に、SQL またはテーブル設計を最適化してください。