Cloud Spannerの結合戦略：クエリプランの「裏側」を制御し、分散データベースを支配せよ
Cloud Spannerは「分散データベースである」という事実を忘れてはならない。単一ノードのRDBMSを扱う感覚でクエリを投げれば、高レイテンシとCPUスパイクの代償を支払うことになる。
特に「結合（Join）」は、Spannerの分散アーキテクチャにおける最大のボトルネックになり得る。今回は、Spannerが内部でどのように結合アルゴリズムを選択し、我々エンジニアがそれをどう制御すべきか、その「極限の知見」を叩き込む。
—
1. Spannerにおける結合の「三種の神器」
Spannerのクエリオプティマイザは、統計情報に基づいて最適な結合アルゴリズムを選択する。しかし、オプティマイザが常に正解を導き出せると信じるのは甘い。我々は以下の3つを理解し、クエリプランを「飼い慣らす」必要がある。
Hash Join：分散環境の主役
- 特性: 片方のテーブル（ビルド側）をメモリ上のハッシュテーブルに展開し、もう片方（プローブ側）を走査する。
- 適性: 大規模なデータセット同士の結合。
- 実務の勘所: 分散環境において、Hash JoinはネットワークI/Oを発生させる可能性がある。特に「大きなテーブル同士の結合」で、もしビルド側のハッシュテーブルがメモリ制限を超えると、ディスクI/Oが発生しパフォーマンスは崩壊する。
Merge Join：ソート済みデータの絶対王者
- 特性: 両方の入力が結合キーでソートされている必要がある。
- 適性: 大規模データかつ、インデックスがキーをカバーしている場合。
- 実務の勘所: 最も効率的だが、ソートのためのコストを評価せよ。`ORDER BY`句が不要な場合でも、インデックスの恩恵を受けてMerge Joinが選ばれるなら、それは最強のクエリプランだ。
Nested Loop Join：局所最適の刺客
- 特性: 外側の行ごとに内側をループ検索する。
- 適性: 片方の入力が極めて小さい（数行程度）、またはインデックスを用いた高速なキー検索ができる場合。
- 実務の勘所: `JOIN`条件にインデックスが効いているなら最速だが、インデックスが効かないNested Loopは「死」を意味する。数十万行をNested Loopで回せば、CPUは即座に枯渇する。
—
2. 実務で遭遇する「罠」と設計パターン
罠：分散結合（Distributed Join）のコスト
SpannerはデータをSplit（分割）して保持している。結合対象のテーブルが異なるノードに散らばっている場合、クエリはノード間通信を伴う。
【設計の鉄則】
- テーブルのインターリーブ（Interleaving）: 親子関係にあるテーブルを物理的に同じSplitに配置せよ。これにより、結合はローカル処理に昇華され、ネットワークオーバーヘッドをゼロにできる。これがSpanner設計の「第一義」だ。
罠：オプティマイザを迷わせるな
複雑すぎるサブクエリや、型不一致（INT64とSTRINGの比較など）は、オプティマイザを機能不全に陥らせ、不適切なアルゴリズム選択を招く。
【改善のテクニック】
— 悪い例：条件式で関数を使ってしまい、インデックスが効かない
SELECT FROM Users u
JOIN Orders o ON u.id = o.user_id
WHERE CAST(u.created_at AS DATE) = ‘2023-10-01’;
— 良い例：インデックスを直接活用し、Merge Joinを誘発させる
SELECT FROM Users u
JOIN Orders o ON u.id = o.user_id
WHERE u.created_at >= ‘2023-10-01’ AND u.created_at < '2023-10-02';
---
3. クエリプランを「強制」するヒント句
オプティマイザが間違った判断をしていると確信できる場合、`FORCE_JOIN_ORDER` や `JOIN_METHOD` ヒントを使って介入することができる。ただし、これは劇薬だ。
— 強制的にHash Joinを選択させるヒント（慎重に使用すること）
SELECT /@ JOIN_METHOD=HASH_JOIN / u.name, o.amount
FROM Users u
JOIN Orders o ON u.id = o.user_id;
チーフアーキテクトからの忠告:
ヒント句を使う前に、まずは「インデックスの再設計」を疑え。ヒントで無理やり結合アルゴリズムを変えるのは、対症療法に過ぎない。インデックスが適切であれば、Spannerのオプティマイザは自ずと正しい道を選ぶ。
—
4. 最後に：エンジニアが向き合うべき指標
Spannerのクエリパフォーマンスを語る際、`CPU usage` だけを見ていては不十分だ。以下の指標を常に監視せよ。
1. `Distributed Union` の発生頻度: どの程度ノード間を跨いでいるか。
2. `Rows scanned`: 結合のためにどれだけの行を読み込んでいるか。
3. `Join latency`: 実行計画のどのノードで時間が溶けているか。
Spannerを使いこなすということは、データの配置（Split）を理解し、クエリプランを数学的に解くということだ。コードを書くとき、常に頭の中でそのクエリが「どのノードで、どのような順序で、どのインデックスを使って結合されるか」を可視化せよ。
それができれば、君のシステムはどんな高負荷にも耐えうる堅牢なアーキテクチャとなるはずだ。期待している。
コメント