【実務・中級編】分散クエリ実行の仕組み – Cloud Spanner

分散クエリの深淵：Cloud Spannerがいかにして「無限」を「一瞬」に変えるのか

Cloud Spannerを「ただのオートスケールするリレーショナルデータベース」だと思っているなら、今すぐその認識を改めたほうがいい。Spannerの本質は、「地理的に分散した数千のノードを、あたかも単一の巨大なコンピュータであるかのように振る舞わせる」という魔法にある。

今日は、Spannerのクエリエンジンが、テラバイト級のデータをミリ秒単位で料理する「分散実行モデル」の裏側を解剖する。設計レビューで私が口うるさく言う「なぜそのクエリが遅いのか」「なぜそのスキーマ設計では詰むのか」の答えがここにある。

—

1. 分散実行モデルの「基本原則」

Spannerのクエリエンジンは、大規模な並列処理（MPP）の哲学を継承している。クエリが投入されると、エンジンはまず「クエリ・プランナー」が論理的な実行計画を立てる。そして、それを「分散実行実行計画」へと分解する。

ここで重要なのは、「データがどこにあるか」をエンジンが完全に把握しているということだ。

Split (スプリット): データは「スプリット」という単位で物理的に分割され、異なるノード（サーバ）に配置される。
クエリの分解: クエリは、各スプリットを担当するノードで実行可能な「サブタスク」に分解される。

2. 結合戦略の「三つの顔」

Spannerが複数ノードにまたがるデータを結合（JOIN）する際、内部では以下のいずれかの戦略が選ばれる。これを知らずにJOINを書くのは、盲目的に高速道路を逆走するのと同じだ。

A. ローカル結合 (Local Join)

最も理想的。JOIN対象のテーブルが「同じスプリット」内（あるいは同じノード内）にある場合だ。

設計の極意: テーブルの主キー設計で「インターリーブ（Interleaving）」を活用せよ。親テーブルと子テーブルを物理的に同じ場所に配置すれば、JOINはネットワークを一切跨がない。これが最強の最適化だ。

B. ブロードキャスト結合 (Broadcast Join)

片方のテーブルが非常に小さい（例：設定値テーブルやマスタ）場合、その小さいデータを「全ノード」にコピーし、各ノードでローカル結合を行う。

注意点: 小さいテーブルであっても、あまりに巨大なデータをブロードキャストさせると、ネットワーク帯域とCPUの無駄遣いになる。

C. シャッフル結合 (Shuffle/Distributed Join)

二つの巨大なテーブルを結合する場合、Spannerはデータを結合キーに基づいて再配置（シャッフル）する。

挙動: 各ノードからデータを読み出し、特定のキーに基づいてネットワーク越しに「結合を行うノード」へ転送する。
パフォーマンス上の警告: これが「重い」原因の筆頭だ。ネットワーク転送コスト（Shuffle Cost）が発生する。これを頻発させるクエリは、いずれシステムを破綻させる。

—

3. 実務で直面する「パフォーマンスの落とし穴」

多くのエンジニアがやりがちなミスを、設計レビューの視点で指摘しておく。

① 「SELECT 」の罪

分散環境において `SELECT ` は自爆行為に近い。

理由: 必要なカラムだけを取得するなら、特定のノードだけで処理が完結することもある。しかし、すべてのカラムを取得しようとすると、不要な巨大データまでネットワークを流れることになる。Spannerは列指向の物理構造を持っている。必要な列だけを射影し、ネットワーク負荷を最小化せよ。

② 不適切なフィルタリング

`WHERE` 句で主キーやインデックスの先頭列を指定しないクエリを投げるな。

コード例:

— 悪い例: 全ノードをフルスキャンさせている
SELECT FROM Orders WHERE status = ‘PENDING’;

— 良い例: インデックスを活用し、特定ノードのみを叩く
— ‘user_id’を条件に加えることで、対象スプリットを特定できる
SELECT FROM Orders WHERE user_id = @user_id AND status = ‘PENDING’;

③ 集計処理の「分散」を意識する

`GROUP BY` を行う際、可能であれば「Partial Aggregation（部分集計）」が自動的に行われるよう設計する。全ノードで一度集計してから、親ノードで最終集計を行うのが鉄則だ。もしクエリが複雑すぎてエンジンが最適化できない場合、中間データが爆発し、メモリ不足でクエリがタイムアウトする。

—

4. エンジニアへの提言：設計の美学

Spannerでシステムを構築するということは、「データが物理的にどこに存在するかを常に意識する」ということだ。

1. インターリーブを極める: 親子関係が明確なテーブルは迷わずインターリーブさせる。これでJOINのコストはゼロに近づく。
2. EXPLAIN ANALYZE を愛せ: クエリを実行して「なんとなく遅い」で済ませるな。`EXPLAIN ANALYZE` を叩き、`distributed union` や `hash join` がどこで発生しているかを視覚化しろ。
3. キー設計が全て: スプリットの境界を意識した主キー設計（単調増加するIDを避けるなど）は、書き込み分散だけでなく、読み取り時のスキャン効率にも直結する。

Spannerは「ブラックボックス」ではない。仕組みを理解し、その上でクエリを投げれば、これほど頼もしい相棒はいない。

さあ、次は君の番だ。コードの中に「分散」という概念を組み込み、世界をスケールさせてくれ。質問があればいつでも聞く。ただし、ドキュメントの最初の一行から読み直してくることだ。