MPPデータウェアハウス

なぜ1台のDBでは分析が詰まるのか

数十億行のイベントログを「日別・地域別に集計せよ」というクエリを考えます。OLTP向けの単一DBは、少数行をインデックスで素早く引くのは得意でも、この種のクエリでは全行に近いスキャンと巨大な集約が必要で、1台のCPU・メモリ・ディスク帯域が律速になります。インデックスを足しても、読むべき行が全体の大半なら効きません。分析ワークロードのボトルネックは「特定行を探す」ことではなく「大量の行を舐めて畳み込む」帯域そのものにあります。

ここでの発想の転換は、速い1台を追うのをやめ、多数の凡庸なマシンにデータを分割して同時に働かせることです。100台で1/100ずつのデータを並列にスキャンできれば、原理上は100倍のスキャン帯域が出ます。これがMPP（Massively Parallel Processing：大規模並列処理）データウェアハウスの核であり、古典的にはAmazon Redshift、Greenplum、Teradata、Verticaなどのシェアードナッシング型がこのモデルを体現してきました（Google BigQueryやSnowflakeも同じ「大量の行を分割して並列に畳む」発想を受け継ぎますが、ストレージと計算を分離した構成をとる点は後述します）。B+木やLSMといった単一ノードのストレージ構造（/database/）の話ではなく、データと計算をどう水平に割るかが主題になります。

シェアードナッシング：分割統治の物理的な土台

MPPが台数比例のスケールを得られるのは、シェアードナッシング（shared-nothing） というアーキテクチャを採るからです。各ノードは自分専用のCPU・メモリ・ローカルディスクを持ち、他ノードと何も共有しません。あるノードが担当するデータには、そのノードだけがアクセスします。

対比すると輪郭がはっきりします。

シェアードナッシングの利点は、競合する共有資源が原理的に存在しないことです。各ノードはローカルディスクをローカルCPUで読むだけなので、100台あれば100本のI/O経路とCPUが独立に動く。ボトルネックは「共有資源の奪い合い」から「ノード間でどれだけデータを動かすか」へ移ります。つまり設計の勝負どころは、各ノードが自分のローカルデータだけで仕事を完結できるように、データをどう配置するかに集約されます。

データ分散：行をどのノードへ置くか

表の各行を物理的にどのノードへ置くかを決めるのが分散（distribution） で、その基準列が分散キー（distribution key） です。代表的な分散方式は3つあります。

ハッシュ分散: node = hash(distkey) mod ノード数
             同じキー値の行は必ず同じノードへ集まる（決定的）

ラウンドロビン分散: 行を順番に各ノードへ均等配置
             データは平準化されるが、値による局所性は無い

全体複製（レプリケート）: 小さい表を全ノードにまるごと複製
             どのノードでもローカルに参照できる（次元表向き）

ハッシュ分散が分析基盤の主役です。キー値のハッシュをノード数で割った余りで宛先が決まるため、同一キー値の行は必ず同一ノードに集まります。この「同じ値が同じ場所に来る」性質が、後述するJOINと集約の効率を根底から支えます。一方で分散キーの選び方を誤ると、特定ノードに行が偏るデータスキュー（偏り） が起き、その1台が最後まで走り続けて全体を遅らせます。理想はカーディナリティが高く（値の種類が多く）、値の出現が均等な列で、order_id のような列が向き、値が数種類しかない status 列などは最悪です。

再分散（シャッフル）：JOINが速くも遅くもなる分岐点

分析クエリの中心はしばしば表と表の結合（JOIN） です。ここでシェアードナッシングの制約が牙をむきます。結合は「両表で結合キーが一致する行どうし」を突き合わせますが、一致すべき行が別々のノードに散っていると、そのままでは突き合わせられません。同じノードに集めてからでないと結合できないのです。

行き着く先は2つに分かれます。

• コロケーテッド結合（co-located join）：結合する両表が同じ列で同じようにハッシュ分散されていれば、キーが一致する行は初めから同じノードに同居しています。各ノードが自分のローカルデータだけで結合を完了でき、ノード間のデータ移動はゼロです。
• 再分散結合（シャッフル）：分散キーが結合キーと違う場合、DBは実行時に片方または両方の表を結合キーで再ハッシュしてネットワーク越しに配り直します。これがデータ再分散（redistribution／シャッフル） で、ネットワーク帯域を大量に消費する最大の遅延源です。

コロケーテッド結合（両表とも customer_id で分散）:
  Node1: orders(cust=1..) ⋈ customers(cust=1..)  ← ローカルで完結、通信なし
  Node2: orders(cust=N..) ⋈ customers(cust=N..)  ← ローカルで完結、通信なし

再分散結合（orders は order_id 分散 → customer_id で配り直す）:
  全ノード → shuffle(customer_id) → 全ノード  ← ネットワークを大量に流れる

もう一つの回避策がブロードキャスト結合（broadcast join） です。片方の表が十分小さければ、それを全ノードへ丸ごと複製して各ノードのローカル大表と結合します。小さな次元表を全ノードに配るコストのほうが、巨大な事実表をシャッフルするより安いときに選ばれます。「大表どうしはコロケーション、大表×小表はブロードキャスト、それ以外はシャッフル」 という判断が、MPPの物理設計とクエリプランの要になります。だからこそ、よく結合する事実表と次元表は同じ分散キーで揃えるのが定石です。

ソートキーとゾーンマップ：ノード内で読む量を削る

分散が「ノード間の配置」を決めるのに対し、ソートキー（sort key） は「ノード内でのデータの並び順」を決めます。この2つは独立した別々の最適化で、混同すると設計を誤ります。分散は並列度とJOINの局所性を、ソートは各ノードが読むブロック量を制御します。

MPPの多くは列指向で、各列を連続したブロック（Redshiftなら1MBブロック等）に格納します。ソートキーでデータを物理的に並べておくと、各ブロックが持つ値の範囲が狭く固まります。ここで効くのがゾーンマップ（zone map／min-maxインデックス） で、これは各ブロックに格納された値の最小値と最大値だけを記録した軽量メタデータです。

sort key = order_date でソート済み、各ブロックの min/max を記録:
  block A: min=2026-01-01  max=2026-01-09
  block B: min=2026-01-10  max=2026-01-18
  block C: min=2026-01-19  max=2026-01-27

WHERE order_date = '2026-01-15' のとき:
  block A → 範囲外なので読まずにスキップ
  block B → 範囲内なので読む
  block C → 範囲外なので読まずにスキップ

クエリの絞り込み条件がソートキーに沿っていれば、DBはゾーンマップを見て該当し得ないブロックを一切読まずに飛ばせます。これをプルーニング（枝刈り） と呼び、行を1件ずつ調べるB木インデックスとは全く別の、「読むブロックを丸ごと減らす」粗い粒度の高速化です。事実表を時刻列でソートしておけば、期間で絞る分析クエリの大半のブロックが読み飛ばされ、スキャン量が桁で減ります。列指向ゆえに必要な列のブロックしか読まない効果と合わせ、I/O量を二重に削るのがMPPのスキャン戦略です。

クエリの並列実行：プランはノードをまたいで組まれる

最後に、1本のSQLがどうやって多数のノードで並列に走るのかを見ます。MPPは通常、クエリを受け付けて全体を統括するリーダーノード（coordinator） と、実データを持って計算する多数のコンピュートノード（worker） に役割が分かれます。

1) リーダーがSQLを解析し、分散を意識した実行プランを作る
2) プランをステージに分割し、各ステージのタスクを全コンピュートノードへ配る
3) 各ノードが自分のローカルデータで、スキャン→フィルタ→部分集約を並列実行
4) 必要ならステージ境界で再分散（シャッフル）してデータを配り直す
5) 各ノードの部分結果をマージして最終結果をリーダーが返す

要はプランがノード間の物理配置を前提に組まれる点が単一DBと決定的に違います。集約 SUM(amount) を例にすると、各ノードがまず自分の持ち分だけを部分集約して小さな中間結果にし、それらだけをネットワークで集めて最終合算します。全生データを1か所へ運んでから畳むのではなく、畳んでから運ぶことで通信量を最小化する——この「部分集約→マージ」の二段構えが並列集約の定石です。プランは複数のステージに分かれ、ステージの切れ目（シャッフルが要る箇所）が並列実行の同期点になります。

まとめ

• MPPデータウェアハウスはシェアードナッシングでデータを多数ノードに水平分割し、各ノードが自分の持ち分を並列にスキャン・集計する。スループットは台数にほぼ比例してスケールし、単一DBでは詰まるテラバイト級の集計を成立させる。
• 何も共有しない代わりに、ノード間のデータ移動量が新たな律速になる。物理設計の目的は「各ノードがローカルデータだけで仕事を完結できる配置」を作ること。
• 最重要変数は分散キー。結合する表を同じキーで分散すればコロケーテッド結合でシャッフルが消え、不一致なら再分散（シャッフル）が起きて遅くなる。小表はブロードキャストで回避する。
• 分散キーは高カーディナリティかつ均等な列を選ぶ。偏るとスキューで最も遅い1台が全体を支配し、スケールアウトでは解消できない。
• 分散（ノード間の配置）とソート（ノード内の並び）は独立。ソートキーとゾーンマップのmin/maxで該当しないブロックをプルーニングし、列指向と合わせてスキャン量を桁で削る。
• クエリはリーダーがプランを分割して全ノードへ配り、各ノードが部分集約してからマージする。並列実行はシャッフルを避ける設計があって初めて速い。