【テクニカル・上級編】結合戦略（Join Strategies） – Cloud Spanner

分散の深淵：Cloud Spannerにおける「Join」を再定義する

Cloud Spannerを単なる「SQLが通る分散データベース」だと考えているなら、それは入り口にすら立っていない。Spannerの真価は、TrueTimeによる強整合性の担保と、その上で繰り広げられる「分散クエリ最適化の極致」にある。

特にJoin戦略は、単なるアルゴリズムの選択ではない。それは、物理的に離れたノード間でのデータフローをいかに最小化し、ネットワークのレイテンシという物理的な壁をどう突破するかという「通信コストとの戦い」そのものだ。

今回は、我々が日常的に扱うSQLの裏側で、Spannerのクエリオプティマイザがどのような「賭け」をしているのか、その深淵を解剖する。

—

1. 物理の制約とJoinの選択基準

Spannerのクエリオプティマイザ（Optimizer）は、単なるコストベースオプティマイザ（CBO）ではない。分散環境特有の「シャッフルコスト」と「データ局所性（Locality）」を最優先で計算する。

Nested Loop Join (NLJ)：極小セットの特権

NLJは、小規模なデータセットや、特定のインデックス経由でターゲットが厳密に絞り込まれている場合にのみ選択される。

深淵の知見: SpannerにおけるNLJの真の脅威は、右側のテーブルへのアクセスがネットワークを跨ぐことだ。もし右側テーブルのキーが対象ノードに存在しない場合、単純なループが指数関数的なRTT（Round Trip Time）の増大を招く。
適応条件: 結合される行数が極めて少なく、かつ右側テーブルがIndex Seekで定数時間に近いレイテンシで引ける場合のみに限定すべきだ。

Hash Join：分散環境の主役

大規模データセットの結合において、SpannerはHash Joinを多用する。

深淵の知見: SpannerのHash Joinは、一方のテーブルをハッシュテーブル化し、メモリ上に展開する。ここで重要なのは「メモリ使用量」だ。大規模な結合でメモリ制限（Nodeのメモリ上限）を超えると、Spannerは即座にDisk Spilling（一時ファイルへの退避）を試みるが、これはクエリのパフォーマンスを壊滅させる。
アーキテクトの視点: クエリ実行計画の `Hash Join` を見たとき、右側の入力が「どれだけ小さいか」を常に意識せよ。大テーブル同士のハッシュ結合は、クラスタの負荷を急上昇させる。

Merge Join：ソート済みデータの恩恵

結合キーが既にインデックス化されており、ソート済みである場合、Merge Joinが最強のアルゴリズムとなる。

深淵の知見: これが「インターリーブ（Interleave）」の真価だ。親テーブルと子テーブルが物理的に同じスプリット内に格納されている場合、ネットワークを跨ぐことなくMerge Joinが完結する。これは分散DBにおける「聖杯」だ。

—

2. 内部メカニズムを操る：クエリプランの最適化

Spannerのクエリプランには、`Distributed Union` や `Cross Apply` といったSpanner固有の演算子が出現する。これらは、分散クエリの「並列性」を制御するための心臓部だ。

実行計画の読み方（極限のヒント）

以下のSQLを想定しよう。

— テーブルAとBを結合。Aは巨大、Bは中規模とする
SELECT A.id, B.val
FROM LargeTableA AS A
JOIN SmallTableB AS B ON A.b_id = B.id

このとき、オプティマイザが `Distributed Cross Apply` を選択した場合、それは「Bの各行に対してAを引く」という戦略をとっている。Bが非常に小さければ、各ノードにBをブロードキャストする（Broadcast Join）方が効率的だ。

パフォーマンスを極限まで引き出すためのチェックリスト:
1. Interleaveの活用: Join頻度が高いテーブルは、必ずインターリーブ設計に組み込む。物理的近接性は、どんなアルゴリズムよりも速い。
2. プランの固定: 予期せぬ実行計画の変更を防ぐため、`OPTIMIZER_VERSION` を固定し、必要に応じて `FORCE_JOIN_ORDER` ヒントを検討する。
3. スプリットの意識: `EXPLAIN ANALYZE` を実行し、`Distributed Union` がどの程度のリモートコールを発生させているか確認せよ。ネットワークI/Oのスパイクは、ほぼここから生まれる。

—

3. 伝説的アーキテクトからの提言

SpannerのJoin戦略を使いこなすということは、「データが物理的にどこにあるか」を脳内でシミュレートすることだ。

多くのエンジニアは「SQLを書けばDBが勝手に最適化してくれる」と信じている。だが、Spannerのような分散DBにおいては、開発者こそがデータ配置の設計者であるべきだ。

結合のパフォーマンスが出ない？ならば、クエリを直す前に「テーブルの物理レイアウト」を見直せ。
Hash Joinのオーバーヘッドが重い？ならば、フィルタリング条件を強め、結合対象のカーディナリティを削れ。

Spannerの内部エンジンは、我々が書いたクエリを物理的なネットワークフローへと変換する「コンパイラ」に過ぎない。そのコンパイラの挙動を理解し、データとアルゴリズムの整合性を突き詰めた者だけが、1ミリ秒のレイテンシを削り出すことができる。

データベースは、単なるデータの箱ではない。設計者の思想を物理的な電脳空間に投影するための、最も純粋なキャンバスなのだ。このキャンバスを使いこなせ。