【テクニカル・上級編】生成列（Generated Columns） – Cloud Spanner

Cloud Spannerの「生成列（Generated Columns）」が変える、分散データベースの物理最適化の極致

Cloud Spannerは、単なる「水平分散可能なSQLデータベース」という枠組みを超え、TrueTimeを軸とした厳密な直列化可能性と分散トランザクションの牙城である。

多くのエンジニアは、生成列を「単なる計算の自動化」と捉えがちだ。しかし、アーキテクトの視点で見れば、これはクエリ実行プランを動的に書き換え、ストレージエンジンレベルでの読み取り負荷を劇的に低減させるための、極めて強力な最適化プリミティブである。

今回は、生成列を単なる利便性のために使うのではなく、Spannerの物理レイアウトとクエリ最適化の観点から徹底的に解剖する。

—

1. 生成列の真の価値：クエリプランの「事前解決」

Spannerにおけるクエリは、ノードごとの計算資源を消費する。特に `WHERE` 句での複雑な関数適用（例：`JSON_EXTRACT` や複雑な文字列加工）は、スキャン時に毎回CPUリソースを奪う。

生成列を定義し、そこに `STORED`（永続化）属性を付与した場合、何が起きるか？

物理ストレージへのマテリアライズ: 計算結果は列データとしてSSTableに書き込まれる。
CPUコストのオフロード: クエリ実行時、計算処理は「実行時」から「データ取得時」へと完全に分離される。
インデックスの即時活用: 生成列に対してインデックスを張ることで、関数適用結果に対して $O(\log N)$ の検索が可能になる。

これは単なる便利機能ではない。計算資源が限られた分散ノードにおいて、クエリの複雑性をストレージレベルで定数時間化するための、極めて高度な戦略的リソース管理である。

—

2. 内部メカニズム：`STORED` か `VIRTUAL` か

Spannerの生成列には、内部的なストレージ消費を伴う `STORED` と、計算結果のみを返す `VIRTUAL`（Spannerではデフォルトの生成列の挙動に準ずる）が存在する。

限界を突破する使い分けの基準

大規模なデータセットに対して `WHERE` 句で複雑なフィルタリングを行う場合、`VIRTUAL` な生成列を使ってインデックスを張ろうとしても、Spannerのオプティマイザはそれを許容しない。なぜなら、その列は「計算結果のキャッシュ」ではなく「式の評価」に過ぎないからだ。

アーキテクトの知見：
頻繁に検索対象となる計算値は、必ず `STORED` を選択せよ。書き込みのレイテンシを懸念するかもしれないが、Spannerの分散ログ（Paxos）への書き込みコストと、クエリ実行時のCPUスパイクによるテールレイテンシを天秤にかけたとき、大抵の場合、`STORED` による物理化の方がシステム全体の安定性に寄与する。

—

3. 実践：JSONフィルタリングの劇的な高速化

現代のアプリケーションで頻出する `JSON` 型の特定のキー値によるフィルタリングを例に挙げよう。

— 生成列を用いた物理最適化の例
ALTER TABLE Users ADD COLUMN user_type STRING(20)
AS (JSON_EXTRACT_STRING(data, ‘$.type’)) STORED;

— インデックスによるルックアップの高速化
CREATE INDEX Idx_Users_Type ON Users(user_type);

なぜこれが最強なのか？

1. 述語プッシュダウンの最適化: オプティマイザは、`JSON_EXTRACT` という不透明な関数を追いかける必要がなくなり、純粋な `user_type` 列に対する等価比較としてプランを生成できる。
2. SSTableのスキャン効率: 生成列は通常の列として物理的に隣接または特定の列ファミリーに配置されるため、ディスク読み取り効率が最適化される。

—

4. チーフアーキテクトからの忠告

生成列を導入する際、以下の3点だけは忘れてはならない。

1. スキーマ変更コスト: `STORED` 生成列を追加する際の `ALTER TABLE` は、既存の全行に対する再計算を伴う。データ量が多い場合、バックグラウンドでの再構築処理がノード負荷を押し上げる。ピーク時間を避け、必ず `Migration` スケジュールを綿密に組むこと。
2. 型変換の罠: 生成列の型定義は厳格である必要がある。計算結果の型がスキーマ定義と不一致を起こすと、書き込み時にトランザクションがアボートする。これはランタイムエラーではなく、分散トランザクションの整合性問題として現れるため、デバッグが極めて困難になる。
3. ストレージ容量のトレードオフ: `STORED` は物理領域を消費する。Spannerはコストがストレージとノード数に比例する。生成列が本当に「クエリのオーバーヘッド削減」に見合うコストかを、`STORAGE_STATS` を見て常に監視せよ。

結びに代えて

生成列は、単なる「便利な糖衣構文」ではない。それは、データベースの物理レイアウトをエンジニアが手動でチューニングするための、極めて洗練されたインターフェースだ。

Spannerを使いこなすということは、データのライフサイクルとアクセスパターンを予測し、ストレージエンジンに何を計算させ、何を保存させるかを完全に制御することに他ならない。

この記事を読んだ諸君には、今日から `AS (…) STORED` を単なる定義文ではなく、「クエリの実行プランを書き換えるための戦略的魔法」として扱ってほしい。それが、世界最高峰のエンジニアへの第一歩である。