Cloud SpannerのPostgreSQLインターフェース：幻想と現実の境界線を見極める
「Google Cloud SpannerがPostgreSQLを喋るようになった」。このニュースを聞いたとき、多くのエンジニアが「これで苦労せずSpannerに移行できる」と歓喜したことだろう。
しかし、現実はそう甘くない。SpannerのPostgreSQLインターフェースは「PostgreSQLそのもの」ではなく、「Spannerの分散データベース・アーキテクチャの上に実装された、PostgreSQLの方言（Dialect）」だ。この本質を見誤ると、リリース後のクエリ爆発や設計の迷走で痛い目を見る。
今日は、SpannerのPostgreSQLインターフェースと真剣に向き合うための「技術的作法」を伝授する。
—
1. 互換性の正体：SQLは同じでも、エンジンは別物
まず頭に叩き込んでおくべきは、「PostgreSQLのバイナリが動いているわけではない」という事実だ。
Spannerは、TrueTimeによる分散トランザクションと、Paxosベースのレプリケーションの上に成り立っている。PostgreSQLの構文を解釈してSpannerの内部表現に変換しているに過ぎない。したがって、以下の制約が「実務上の壁」として立ちはだかる。
サポートされるデータ型と「暗黙の罠」
基本的なデータ型（`INT8`, `VARCHAR`, `TIMESTAMP`, `JSONB`など）は概ねサポートされている。しかし、PostgreSQLに慣れ親しんだエンジニアが躓きやすいのがこれだ。
- `SERIAL`や`IDENTITY`は使えない: 分散環境においてシーケンシャルなID発行はパフォーマンスのボトルネック（ホットスポット）になる。Spannerでは`UUID`または`BIT_REVERSED_POSITIVE_INT`（分散に最適化されたID）を使用するのが定石だ。
- `JSONB`の扱い: PostgreSQLの`JSONB`は非常に柔軟だが、SpannerでJSONBを使う際は「インデックス設計」に注意が必要だ。特定のフィールドを検索したいなら、JSON内のパスを抽出する生成列（Generated Columns）を定義し、そこにインデックスを貼るのが鉄則だ。
—
2. 関数と構文の制限：なぜ「使えない」のかを理解せよ
Spannerのクエリオプティマイザは、分散クエリを前提としている。そのため、PostgreSQLの「標準的だが重い」操作が制限されているケースが多い。
避けるべき、または代替すべきパターン
- サブクエリの相関: 巨大なテーブルに対する相関サブクエリは、ノードを跨いだ結合を引き起こし、地獄のようなレイテンシを生む。
- 複雑なストアドプロシージャ: SpannerのPGインターフェースではPL/pgSQLをサポートしない。複雑なロジックはアプリケーション層に逃がすか、Spannerの強力なマルチステートメントトランザクションを活用して設計し直す必要がある。
実務での設計パターン：`JOIN`の最適化
Spannerで最も重要なのは「データの局所性」だ。
— 悪い例：インデックスがないカラムでのJOIN
— 巨大なデータセットを全ノードにブロードキャストして結合しようとする
SELECT FROM Orders o
JOIN LineItems li ON o.order_id = li.order_id
WHERE o.status = ‘PENDING’;
— 良い設計：インタリーブ（Interleave）を活用する
— 親テーブル(Orders)と子テーブル(LineItems)を物理的に同じスプリットに配置し、
— 結合コストを極限まで下げる。これがSpannerの真骨頂。
—
3. パフォーマンス上の注意点：分散DBの「重力」を意識する
PostgreSQLの感覚でクエリを書くと、Spannerの分散環境では「パフォーマンスの重力」に押しつぶされる。
1. Full Table Scanの撲滅: スキーマ設計時にプライマリキーを適切に選定できていないと、全ノードをスキャンすることになる。Spannerでは「どのノードがデータを持っているか」を意識したクエリ設計が必須だ。
2. トランザクションの肥大化: PostgreSQLなら許容されるような長大なトランザクションは、Spannerでは競合による「Abort」を誘発する。トランザクションは可能な限り短く、そして小さく保て。
3. `EXPLAIN ANALYZE`を宗教のように崇めろ: クエリを実行する前に必ず実行計画を見ろ。`Distributed Union`や`Global Sort`などのキーワードが表示されたら、それはパフォーマンス劣化のサインだ。
—
4. チーフアーキテクトからの助言
PostgreSQL互換インターフェースは、既存のツール（ORMやマイグレーションツール）を流用できるという点では非常に強力だ。しかし、「移行の手間を減らすこと」と「Spannerの性能を最大限に引き出すこと」は別次元のタスクだ。
もしあなたが、「PostgreSQLのクエリをそのまま流し込んで終わり」と考えているなら、今すぐその考えを捨てろ。
- データモデルをSpannerのアーキテクチャ（インタリーブ、ホットスポット回避）に合わせる。
- PostgreSQLの機能に依存せず、Spannerの分散特性に合わせたクエリを書く。
- アプリケーション層でトランザクションの粒度を制御する。
これらを守れるチームだけが、Spannerの「無限に近いスケーラビリティ」と「強整合性」という恩恵を享受できる。
Spannerは、単なるデータベースではない。分散システムという広大な荒野を駆け抜けるための、最強のエンジンだ。そのスペックを活かすも殺すも、設計者の「理解度」次第である。
さあ、コードを開け。あなたのクエリは、分散の世界で最適化されているか？
コメント