Cloud Spannerの深淵：実行計画（Execution Plan）から読み解く分散クエリの真実
多くのエンジニアが「Cloud Spannerは無限にスケールするマネージドDBだ」と語る。しかし、それは表面的な理解に過ぎない。Spannerの真価は、分散システムでありながら、単一ノードのリレーショナルデータベースと同等のACID特性を維持し、かつ「並列分散クエリエンジン」としていかに低レイテンシで実行計画を最適化するかという一点に集約される。
実行計画（Execution Plan）は、Spannerという巨大な機械が、あなたのクエリに対してどのような「生存戦略」を立てたのかを記した航海日誌である。これを読み解けない者に、数百万TPSを捌くシステムを設計する資格はない。
—
1. 分散実行計画の解剖学：Distributed Unionの正体
Spannerの実行計画において、最も頻繁に、そして最も重要視すべき演算子が `Distributed Union` である。これは単なる「並列実行」を意味しない。
- Distributed Union: クエリを複数のスプリット（データ断片）に対して並列発行し、その結果を統合するゲートウェイ。
- 深層知見: この演算子が吐き出されている場合、クエリは複数のサーバー（ノード）を跨いでネットワークI/Oを発生させている。もし、あなたのクエリ計画に `Distributed Union` が頻出しているなら、それはデータ配置（Interleaving）の失敗か、あるいは索引設計が不十分であることを意味する。
プロの視点: 実行計画を眺める際、まず `Distributed Union` の子ノードに注目せよ。そこに `Table Scan` があれば、それは「フルスキャンが走っている」という警告音だ。
2. 「コスト」の欺瞞とメモリ最適化の極意
Spannerのオプティマイザは、CPUとネットワークコストを動的に見積もる。しかし、統計情報（Statistics）が古い場合、オプティマイザは平気で「Nested Loop Join」を選択し、悲劇を招く。
メモリ最適化のチェックリスト
実行計画の各演算子には `Memory usage` の推計値が含まれることがある。特に注意すべきは以下の演算子だ。
- Hash Join: メモリを大量に消費する。巨大なテーブル同士の結合でこれが発生している場合、メモリ不足（OOM）でクエリが打ち切られるリスクがある。
- Sort: 巨大なデータセットに対するソートは、ネットワーク越しのデータ転送を引き起こし、クエリのレイテンシを指数関数的に増大させる。
— 実行計画を確認するコマンド
— EXPLAIN ANALYZE を使うことで、見積もりと実測の乖離を特定する
EXPLAIN ANALYZE SELECT FROM Users u JOIN Orders o ON u.id = o.user_id WHERE u.status = ‘ACTIVE’;
極限の知見: `EXPLAIN ANALYZE` の結果を見て、`Actual rows` と `Estimated rows` に大きな乖離がないかを確認せよ。乖離がある場合、Spannerは実態と異なる「偽りの計画」で実行している。これは統計情報の更新を促す合図である。
3. スキャン方法：物理的な効率性の追求
`Index Scan` か `Table Scan` か。この選択肢の先にあるのは、物理的なディスク読み取り量（IOPS）の削減である。
1. Index Scan: インデックスのみで完結するクエリ（Covering Index）は、メインテーブルへのアクセスを不要にする。これはSpannerにおいて最強の最適化だ。
2. Table Scan (Full Scan): これを検知したら、直ちにプロファイラを回せ。特定のキー範囲に絞り込めていない、つまり `WHERE` 句のフィルタリングがインデックスを活用できていない証拠である。
— 悪い実行計画の例
Distributed Union
|– Table Scan (Table: Orders) <-- 警告：フルスキャンしている
|-- Filter (Status = 'ACTIVE') <-- 警告：スキャンした後にフィルタしている
この場合、`CREATE INDEX` で `Status` を含めるか、あるいは `Storing` 句を使って必要なカラムをインデックス側に寄せる（Covering Index化する）ことで、`Table Scan` を `Index Scan` へと昇華させる必要がある。
4. 伝説のアーキテクトからの提言：クエリは「書く」ものではなく「生成させる」もの
多くの初心者は、複雑なSQLを書いて満足する。だが、熟練者は「オプティマイザが好むSQL」を書く。
- 結合の順序: `JOIN` を行う際は、可能な限り絞り込まれた結果セットを左側に置くのが定石だが、Spannerのオプティマイザはこれを自動で最適化する。しかし、ヒント句（`FORCE_JOIN_ORDER`）に頼る前に、まずスキーマの Interleave（テーブルの親子関係の物理的配置）を見直せ。
- クエリパラメータ: リテラル値を直接埋め込むな。パラメータ化することで、Spannerはコンパイル済みのクエリ計画を再利用（Plan Cache）でき、大幅にレイテンシを削減できる。
結び：深淵を覗く者へ
Cloud Spannerの実行計画は、単なるテキストではない。それは、世界中に散らばった数ペタバイトのデータが、光の速さで集約され、あなたのアプリケーションに届くまでの物理的な旅路だ。
「なぜこのクエリは遅いのか？」という問いに対し、実行計画は常に答えを持っている。演算子の一行一行、コストの推計値一つ一つに、データベースエンジン開発者たちの執念が宿っている。
その行間を読み解けたとき、あなたは初めてCloud Spannerを「使いこなした」と言えるだろう。コードを書くことだけに満足するな。その裏側で駆動する巨大なエンジンと対話し、極限まで無駄を削ぎ落とせ。それがエンジニアとしての真の生存戦略である。
コメント