【実務・中級編】データ型のマッピングと互換性 – Cloud Spanner

Cloud Spannerの魂：GoogleSQLとPostgreSQLダイアレクト、その「選択の哲学」とデータ型設計

Spannerの真価は、単なる「分散RDB」という枠組みを超えた、極限の可用性と一貫性の両立にある。しかし、多くのエンジニアが設計の入り口で立ち止まるのが、「GoogleSQL（旧標準SQL）にするか、PostgreSQLダイアレクトにするか」という問いだ。

これは単なる方言の選択ではない。データ型の扱い、アプリケーションとの親和性、そして将来的なエコシステムへの適応力を左右する「設計の基盤」そのものだ。今日は、Spannerのアーキテクチャの深淵を知る者として、この選択とデータ型マッピングの要諦を叩き込む。

—

1. 概念としての「ダイアレクト」を理解せよ

Spannerの内部エンジンは一つだが、インターフェース層が異なる。

GoogleSQL: Spannerネイティブの進化形。Googleの分散システムとしての最適化が最も進んでいる。
PostgreSQLダイアレクト: PostgreSQLプロトコルとの互換性を重視。既存のツール（ORMやマイグレーションツール）を流用したい場合に選ぶ。

ここで重要なのは、「型変換のコストを意識せよ」ということだ。例えば、GoogleSQLの `TIMESTAMP` はSpannerのネイティブな時間軸に最適化されているが、PostgreSQLダイアレクトでは `TIMESTAMPTZ` として振る舞う。この微妙なズレが、複雑なクエリの実行計画に影響を及ぼすことを忘れてはならない。

2. データ型マッピングの「罠」と「最適解」

実務で最も衝突するのは、型定義の非対称性だ。以下の表は、特に注意すべきマッピングの要点である。

設計上の極限の知見：

JSONBの誘惑: PostgreSQLダイアレクトを選択する最大の理由は、`JSONB` の存在だ。複雑なドキュメント構造をインデックス化して高速に検索したいなら、PostgreSQLダイアレクトを選んだほうが設計の自由度は格段に上がる。
STRING(MAX)の過信: GoogleSQLで `STRING(MAX)` を多用する設計は、スキーマ設計の怠慢だ。インデックスを貼る際は、`STRING(256)` のようにサイズを限定せよ。これがクエリの実行効率を劇的に改善する。

—

3. 堅牢な設計パターンの伝授

コードレビューで私が必ずチェックするポイントがある。それは「型変換をSQL内で発生させていないか」だ。

— 悪い例: インデックスが効かない可能性がある
SELECT FROM Users WHERE CAST(created_at AS STRING) = ‘2023-10-01’;

— 良い例: 型を完全に一致させ、比較演算子をクリーンに保つ
SELECT FROM Users WHERE created_at = TIMESTAMP(‘2023-10-01 00:00:00+00’);

パフォーマンスを左右する「主キーの型」

Spannerの主キーにおいて、型選択はパフォーマンスに直結する。`UUID` を使う場合、GoogleSQLでは `STRING(36)` を使うことが多いが、PostgreSQLダイアレクトならネイティブの `UUID` 型が使える。
結論: メモリ消費とインデックスの断片化を避けるため、可能な限り `INT64` (順序性のあるID) または `BYTES(16)` を推奨する。UUIDを文字列で保持するのは、スケーラビリティの観点からは「罪」に近い。

—

4. 移行と運用：テクニカルリードからの助言

「PostgreSQLだからSpannerでも同じように動くだろう」という考えは捨てろ。Spannerは分散データベースであり、「単一のトランザクション内で広範囲な行をロックする」ような設計は、PostgreSQLのそれよりも遥かにコストが高い。

マイグレーション: `pg_dump` は万能ではない。Spannerの `INTERLEAVE IN PARENT`（テーブルの親子関係による物理的近接化）を最大限活用できるよう、スキーマ定義を再構築せよ。
アプリケーションコード: ORMに依存しすぎると、Spanner特有の効率的なクエリ（`FORCE_INDEX` や `JOIN` のヒント句）が書けなくなる。パフォーマンスが重要なクエリは、必ずORMから切り離し、生SQL（あるいはQuery Builder）で制御せよ。

最後に：どちらを選ぶべきか

もしあなたが「PostgreSQLの既存資産を活かしつつ、グローバルな水平スケーリングを手に入れたい」のであれば、迷わず PostgreSQLダイアレクト を選べ。

しかし、もしあなたが「Spannerの全機能を使いこなし、極限のパフォーマンスを追求したい」のであれば、GoogleSQL こそが唯一の選択肢だ。

エンジニアリングに魔法はない。あるのは「データが物理的にどう配置され、どう検索されるか」を論理的に積み上げる誠実な設計だけだ。君たちの次の設計が、Spannerのポテンシャルを最大限に引き出すことを期待している。

何か困ったことがあれば、いつでもコードを見せてくれ。厳しく、しかし愛を持ってレビューしよう。