【テクニカル・上級編】 PostgreSQLダイアレクトの互換性 – Cloud Spanner

Cloud SpannerにおけるPostgreSQLダイアレクトの「幻想と物理」：アーキテクトが直視すべき限界

Cloud SpannerがPostgreSQLインタフェース（PGダイアレクト）を実装したことは、単なる「互換レイヤーの追加」ではない。それは、Googleの分散データベースの深淵に、PostgreSQLのSQLセマンティクスを強制的に埋め込むという、極めて野心的な工学的挑戦だ。

多くのエンジニアが「PostgreSQLがそのまま動く」と誤解しているが、それは罠だ。我々アーキテクトが理解すべきは、「SQLの見た目」の裏側で、分散トランザクション（TrueTime）と物理的なデータ配置がどう衝突し、あるいは調和しているかという一点に尽きる。

—

1. 物理配置の制約：なぜ「PostgreSQLの全機能」は存在し得ないのか

Cloud Spannerの核心は、データが「スプリット（Split）」され、ノード間で動的に分散されることにある。PostgreSQLの構文を解釈するパーサーが、どのようにこの分散レイヤーを叩いているかを理解しなければならない。

データ型の物理的制約: Spannerのデータ型は、Spanner固有のストレージフォーマットにマッピングされる。例えば、`JSONB`はPostgreSQLのオンディスクフォーマットとは別物だ。Spanner上のJSONBは、クエリエンジンがインデックスを効率的にスキャンできるように構造化された最適化データとして保持される。
関数のプッシュダウン: 全てのPostgreSQL関数がサポートされているわけではない。なぜか？それは「分散クエリエンジンへのプッシュダウンが不可能、あるいは非効率だから」だ。特定の関数がノードを跨いだスキャンを誘発し、メモリを枯渇させるリスクがある場合、Spannerはあえてその実装を拒否する。

2. PostgreSQL固有構文の「落とし穴」：分散トランザクションとの衝突

PostgreSQLで当然のように使われる機能が、Spannerの分散アーキテクチャでは「アンチパターン」になるケースがある。

シーケンス（Sequences）の限界

PostgreSQLでは`SERIAL`や`SEQUENCE`を多用するが、SpannerのPGダイアレクトにおいて、これらは「分散ロックのボトルネック」になり得る。

— PostgreSQL互換モードでのシーケンス生成
— これを頻繁に呼び出すと、分散した各ノードが単一のメタデータサーバーへ
— 連続的に競合アクセスを行うことになり、TrueTimeの同期コストと相まって
— スループットが劇的に低下する。
CREATE SEQUENCE user_id_seq START 1;

アーキテクトの視点: 分散システムにおいて、単調増加するIDを生成するコストは極めて高い。Spannerでこれをやるなら、UUID（`GENERATE_UUID()`）による衝突回避、あるいは`bit-reversed`なID生成を推奨する。DBエンジン側にロジックを委ねるな。

3. メモリ最適化と実行計画：クエリの「重さ」を読み解く

PostgreSQLの実行計画（`EXPLAIN`）とSpannerの実行計画は、出力されるツリー構造は似ていても、コストの計算法が根本的に異なる。

Distributed Cross-Apply: Spannerの実行計画に頻出するこのオペレータは、分散されたデータに対する「ジョインの再帰」を意味する。PGダイアレクトを使用している際、複雑なサブクエリを書くと、この演算がメモリを食いつぶす。
インデックスの物理設計: PostgreSQLでは「とりあえずインデックス」だが、Spannerではインデックスもまた物理的に独立したテーブルとして扱われる。`INCLUDE`節を使用したカバリングインデックスの利用は必須であり、これを行わないクエリは、ノード間のネットワークI/Oを徒に増大させる。

— 推奨されるインデックス設計
— PGダイアレクトであっても、Spannerの物理構造を意識した
— インデックス設計が性能の9割を決定する。
CREATE INDEX idx_user_email_name
ON users(email) INCLUDE (name);
— この”INCLUDE”が、フェッチ処理を減らしネットワークオーバーヘッドを極小化する

4. 結論：何を捨て、何を選ぶべきか

Cloud SpannerのPostgreSQLインターフェースは、PostgreSQLの「互換性」を維持しつつ、Spannerの「水平スケーラビリティ」を享受するための橋渡しに過ぎない。

真のアーキテクトへの助言:
1. 手続き型コードの排除: ストアドプロシージャや関数にロジックを詰め込むのはやめろ。分散DBにおいて、計算コストの高い処理をDBノード上で走らせるのは、スケーラビリティの放棄と同義だ。
2. トランザクションの粒度: PostgreSQLの感覚で長大なトランザクションを維持すれば、Spannerは容赦なくロック競合でシステムを停止させる。トランザクションは可能な限り短く、そして分散を考慮した設計（ホットスポットを避けるキー設計）を徹底せよ。
3. 互換性は「移行の手段」であって「目的」ではない: PostgreSQLライクに書けることは、PostgreSQLの設計思想をそのまま持ち込めることを意味しない。

Cloud Spannerの真価は、そのSQLの書き方にあるのではなく、その「極限まで抽象化された分散ストレージの上で、いかに物理的なパフォーマンスを引き出すか」という設計の最適化にある。

この壁を越えた先にあるのは、単なるデータベースではなく、無限に拡張可能な「データの宇宙」だ。仕様書を読み込むだけでは到達できない、実装の深淵へ踏み込む準備はできているか。