【テクニカル・上級編】クエリヒント – Cloud Spanner

クエリ・オプティマイザを飼いならす：Cloud Spannerにおける実行計画制御の「深淵」

Cloud Spannerは「水平スケールするRDBMS」という謳い文句で語られがちだが、その本質は分散トランザクションを並列実行するための高度な計算エンジンである。

多くのエンジニアは、Spannerのオプティマイザを「ブラックボックス」として扱い、パフォーマンスが劣化すると「インデックスが足りない」と短絡的に結論づける。だが、Spannerのクエリエンジンがなぜその実行計画を選んだのか、その裏側にあるコストモデルを理解せずにチューニングを行うのは、目隠しをしてF1を運転するようなものだ。

今回は、Spannerのクエリヒント（`FORCE_JOIN_ORDER` や `JOIN` メソッドの指定）を軸に、オプティマイザの挙動と、それをいかに強制的に制御すべきか、その極限の知見を共有する。

—

1. オプティマイザの「迷い」を読み解く

Spannerのクエリ・オプティマイザは、基本的にはコストベース（CBO）で動く。だが、分散環境特有の「ネットワークレイテンシ」と「ノード間通信コスト」が加わるため、従来のRDBMSよりもはるかに複雑な計算を行っている。

特に、データ分布が偏っている場合や、統計情報が最新でない場合、オプティマイザは「Nested Loop Joinが最適」と判断すべき場所で「Hash Join」を選択し、メモリを食いつぶすことがある。

FORCE_JOIN_ORDER：探索空間の剪定

`FORCE_JOIN_ORDER` を使うことは、単なる指示ではなく、オプティマイザによる広大な探索空間の探索を放棄させることを意味する。

結合順序を強制することで、意図しない中間結果セットの増大を抑制する。
分散JOINにおいて、最もカーディナリティ（行数）が小さいテーブルを
早期にDriveさせるのが鉄則。

/
SELECT /@ FORCE_JOIN_ORDER=TRUE /
t1.id, t2.data
FROM Users AS t1
JOIN Orders AS t2 ON t1.id = t2.user_id
WHERE t1.status = ‘ACTIVE’;

このヒントを使用する際は、実行計画（`EXPLAIN ANALYZE`）を必ず見よ。結合順序を変えた結果、各ノード間でやり取りされるデータ量（`distributed union` のスキャン量）が劇的に減っているはずだ。

—

2. JOINメソッドの選定：メモリと速度のトレードオフ

SpannerのJOINメソッド（`HASH JOIN`, `APPLY JOIN`）を制御することは、メモリ利用率の限界を突破する鍵となる。

HASH JOINの罠

`HASH JOIN` は大量データに対して強力だが、ビルド側のテーブルがメモリに乗らない場合、Spannerはディスクへの退避（Spill）を試みる。これはレイテンシの劇的な悪化を招く。

APPLY JOIN（Nested Loop）の真実

`APPLY JOIN`（いわゆるNested Loop）は、右側のテーブルがインデックスによって効率的にルックアップできる場合にのみ真価を発揮する。

結合対象のテーブルが十分に小さく、かつインデックス経由のルックアップが
決定的な速度を持つ場合にのみHASH JOINを禁止する。

/
SELECT /@ JOIN_METHOD=APPLY_JOIN /
u.id, o.order_date
FROM Users AS u
JOIN Orders AS o ON u.id = o.user_id
WHERE u.id = @target_user_id;

極限の知見：
なぜ `APPLY JOIN` をあえて指定するのか？それは、オプティマイザが「統計情報の誤認」によって誤った `HASH JOIN` を選ぶケースを回避するためだ。特に、クエリの実行頻度が高く、かつ特定IDへのアクセスに偏りがある場合、`APPLY JOIN` の決定論的な挙動はシステムの予測可能性（Predictability）を大きく向上させる。

—

3. なぜ「ヒント」が必要なのか：アーキテクトの視点

ヒントを使用することは「オプティマイザへの敗北」ではない。むしろ、データベースの物理的なデータ分布をコードで言語化する行為である。

Spannerのクエリエンジンは、以下の要素でコストを算出している。
1. スキャンコスト：どのインデックスを使い、どの程度の範囲を走査するか。
2. コミュニケーションコスト：ノード間でどれだけのデータを転送するか。
3. メモリコスト：ハッシュテーブルにどれだけのメモリを割り当てるか。

時折、この計算式が「現実のデータ分布」と乖離することがある。例えば、`WHERE` 句のフィルタリングによって99%が排除されるような場合、オプティマイザがその選択性を正確に見積もれないことがある。その瞬間こそが、熟練エンジニアの出番だ。

—

結論：チューニングの作法

ヒントを闇雲に使うのは厳禁だ。以下の手順を鉄則とせよ。

1. `EXPLAIN ANALYZE` を叩く: 実行コストの大部分がどこにあるか（Scanか、Joinか、Sortか）を特定する。
2. 統計情報の確認: 最新の `ANALYZE` が実行されているかを確認し、それでも解消しない場合のみヒントを検討する。
3. 副作用の検証: ヒントを追加したことで、別のクエリパターンへの影響（プラン・キャッシュの汚染など）がないかを本番負荷に近い環境で検証する。

Cloud Spannerは、現代の分散データベースにおける「頂点」だ。そのエンジンを操るということは、数学的モデルと現実の物理的なデータ分布のギャップを埋める作業に他ならない。

ツールに遊ばれるな。ツールを掌の上で転がせ。それこそが、真のアーキテクトの矜持だ。