【テクニカル・上級編】テーブル定義とデータ型 – Cloud Spanner

Cloud Spannerの真髄：テーブル定義とデータ型が「分散」に与える静かなる支配

多くのエンジニアは、Cloud Spannerを「無限にスケーリングするRDBMS」という謳い文句で理解している。だが、真のアーキテクトにとって、Spannerは単なるデータベースではない。それは「巨大な分散型キー・値ストアの上に構築された、厳密な整合性を保証するための時空間シミュレーター」だ。

今回は、テーブル定義とデータ型という最もプリミティブなレイヤから、Spannerの内部アーキテクチャがどう反応し、パフォーマンスがどう決定されるのかを深掘りする。

—

1. Primary Key：物理的コロケーションの支配者

Spannerにおけるテーブル定義の要諦は、SQLの構文ではない。「物理的なデータ配置（Data Placement）」の設計である。

CREATE TABLE Users (
UserId INT64 NOT NULL,
RegionId INT64 NOT NULL,
Data JSON,
) PRIMARY KEY (RegionId, UserId);

この定義において、`PRIMARY KEY`は単なる一意性制約ではない。Spannerの内部では、データはキーの昇順でSplit（分割単位）に管理される。

`RegionId`を先頭に置くことで、特定のリージョンやテナントのデータを物理的に隣接させ、範囲スキャン（Range Scan）の効率を最大化できる。
注意すべきは、「ホットスポット」の回避だ。単調増加するIDを先頭にすると、末尾のSplitに全ての書き込みが集中し、Spannerの真骨頂である分散並列性能が死ぬ。これを防ぐには、`UUID`の使用や、IDのビット反転、あるいはハッシュ化によるシャーディングが必須となる。

2. データ型と「ストレージ・ペナルティ」の真実

データ型は、単なるバリデーションルールではない。これはSpannerのストレージエンジンにおける「シリアライズコスト」と「メモリ消費量」に直結する。

STRING vs BYTES

`STRING`型はUTF-8エンコーディングを強制する。もしアプリケーション層でBase64エンコードされたバイナリを文字列として保存しているなら、それはアーキテクチャの敗北だ。`BYTES`型を使うべきである。`BYTES`は比較操作がバイナリレベルで完結するため、オーバーヘッドが極小化される。

ARRAYの罠

`ARRAY`は非常に強力だが、使いどころを誤ると悲劇を招く。
Spannerにおいて`ARRAY`は、行内の1つのカラムとして格納される。もし1つの行に巨大な配列を突っ込むと、その行は非常に肥大化し、Splitの境界をまたぐ際のマイグレーションコストが跳ね上がる。
「配列内の要素を頻繁に更新する」設計はNGだ。 配列の一部を書き換えるだけでも、行全体を書き換えるコスト（トランザクションログの増大）が発生するからだ。

JSON：柔軟性の代償

`JSON`型は、Spanner内部では`JSONB`のように効率的なバイナリ形式で保持される。しかし、インデックスを貼らない限り、内部フィールドの検索はフルスキャンに等しい。

— JSON内の特定フィールドにインデックスを貼る際の最適化
CREATE INDEX UserProfilesByEmail ON Users (JSON_VALUE(Data, ‘$.email’));

このインデックスは、Spanner内部で「関数インデックス」として処理される。つまり、書き込みのたびにこのJSONをパースして値を抽出するコストが発生する。柔軟性と書き込み性能のトレードオフを理解せよ。

3. 分散トランザクションとデータ型の相関

Spannerのトランザクションは、2PC（2フェーズコミット）とPaxosを組み合わせた強固な仕組みだ。データ型とサイズが重要な理由は、「トランザクションが保持できるペイロードサイズには制限がある」からだ。

1トランザクションあたりの書き込みサイズ制限（通常10MB程度）に達すると、コミット時にエラーを返す。
`STRING`や`ARRAY`を多用し、巨大なオブジェクトを頻繁に更新する設計は、この物理的制限に衝突する可能性を高める。

—

4. 伝説のアーキテクトからの提言：最適化の極意

限界まで性能を引き出すために、以下の指針を胸に刻んでほしい。

1. 固定長を愛せ: 可能な限り`INT64`や`FLOAT64`を優先せよ。可変長データ（`STRING`, `BYTES`）は、ストレージ断片化とインデックス構築コストの増大を招く。
2. インデックスは「必要悪」と見なせ: インデックスは読み取りを高速化するが、書き込みを重くする。Spannerは分散システムだ。インデックスが増えるたびに、Paxosグループを跨ぐ調整コスト（レプリケーションコスト）が増大する。
3. タイムスタンプの運用: `TIMESTAMP`型には`OPTIONS (allow_commit_timestamp=true)`を付与せよ。これがSpannerの分散トランザクション整合性を支える肝であり、真の「時刻同期」の恩恵を受ける唯一の方法だ。

最後に：コードは嘘をつかない

Spannerのテーブル定義は、システム全体のデータフローを定義する設計図である。
適当にカラムを並べるのではなく、「どのデータとどのデータが同じSplitに配置されるべきか」を想像せよ。

データ型一つ、インデックス一つに、Spannerの分散エンジンがどう反応するか。その「解像度」こそが、君をただのエンジニアから、システムを支配するアーキテクトへと引き上げる。

さあ、次はクエリプランの深淵へ潜る準備をするとしようか。