Cloud SpannerのGoogleSQLを「使いこなす」：理論と実践の境界線
Cloud Spannerを単なる「リレーショナルデータベース」だと思っているなら、今すぐその認識を改める必要がある。SpannerはGoogleの分散システム技術の結晶であり、そこで駆動するGoogleSQLは、単なるSQLの互換実装ではない。
今日は、Spannerのポテンシャルを最大限に引き出すためのGoogleSQLの「作法」について、現場の知見を叩き込む。
—
1. データ型設計：後悔しないための選定基準
Spannerのデータ型選択は、単なるストレージ節約の問題ではない。分散トランザクションのパフォーマンスに直結する。
最適な選択の勘所
- `STRING(MAX)` は禁忌: 多くの初学者がやりがちだが、`STRING(MAX)`はインデックスサイズを肥大化させ、スキャン効率を著しく低下させる。長さが決まっているなら、必ず`STRING(n)`で定義せよ。
- `NUMERIC` vs `FLOAT64`: 金融系や厳密な計算が必要なフィールドには必ず`NUMERIC`を使うこと。`FLOAT64`は近似値であり、端数計算で地獄を見る。
- `TIMESTAMP`の取り扱い: `TIMESTAMP`は常にUTCで保存する。クライアント側でのタイムゾーン変換は言語層の責務だ。また、`allow_commit_timestamp=true`オプションを活用し、データベース側の確実なコミット時間を活用せよ。
— 良い設計例: 長さを制限したSTRINGと、コミット時間を追跡するTIMESTAMP
CREATE TABLE Orders (
OrderId STRING(36) NOT NULL,
Amount NUMERIC NOT NULL,
CreatedAt TIMESTAMP NOT NULL OPTIONS (allow_commit_timestamp = true)
) PRIMARY KEY (OrderId);
—
2. 識別子とネーミング：分散環境での「読みやすさ」
Spannerはグローバルにスケールする。数千のテーブルや数万のインデックスを扱う将来を見据えた命名規則が必要だ。
- 予約語との衝突回避: GoogleSQLのキーワード（`SELECT`, `FROM`, `WHERE`など）を識別子に使うな。もし重複が避けられない場合は、バッククォート（“ ` “）で囲むのが基本だが、そもそも設計段階で避けるべきだ。
- CamelCase vs snake_case: プロジェクト内で統一されていればどちらでも良いが、私は`snake_case`を推奨する。DBメタデータや外部ツールとの親和性が高く、可読性が高いからだ。
—
3. クエリのパフォーマンスを殺さない「演算子」の鉄則
Spannerにおいて、クエリは「分散実行」される。演算子の使い方が、ノード間の不要なデータ転送（シャッフル）を招く。
「インデックスが使われない」クエリを撲滅する
`WHERE`句でカラムに対して関数を適用してはいけない。
— 悪い例: 関数を適用するとインデックスが効かない（フルスキャン確定）
SELECT FROM Orders WHERE LOWER(OrderId) = ‘abc-123’;
— 良い例: アプリケーション側で正規化してからクエリを投げる
SELECT FROM Orders WHERE OrderId = ‘abc-123’;
—
4. 堅牢な設計パターン：パラメータ化クエリは「必須」
これは開発者の義務だ。文字列結合でクエリを組み立てるなど論外である。
- SQLインジェクション対策: 言うまでもないが、パラメータ化クエリ（`@param`）を使用することで、プランキャッシュの効率も向上する。Spannerはクエリの形状を解析して実行計画を立てる。パラメータ化は、このキャッシュ効率を最大化する鍵だ。
— 効率的なパラメータ化クエリの例
SELECT
OrderId,
Amount
FROM Orders
WHERE CreatedAt > @start_time — クエリプランが再利用される
—
5. チーフアーキテクトからの助言
最後に、実務でSpannerを扱う際の「極意」を伝授する。
1. 実行計画（Query Plan）を見ろ: `EXPLAIN ANALYZE`を恐れるな。実行計画を見れば、どの演算子がボトルネックになっているか、どこのインデックスが使われていないか一目瞭然だ。
2. JOINのコストを意識せよ: 分散環境において、大規模テーブル同士のJOINは極めて高コストだ。必要に応じて非正規化を検討し、単一分割（Split）内で完結するクエリを意識する設計こそが、Spannerの真骨頂である。
3. 読み取り専用トランザクションの活用: 読み取りのみの処理であれば、`ReadOnlyTransaction`を利用せよ。これにより、書き込みロックの競合を回避し、システムの可用性が劇的に向上する。
—
Spannerは、正しく使えば最強の武器だが、甘く見れば開発者の足を引っ張る。
GoogleSQLを「単なる言語」と捉えず、「分散システムを制御するためのインターフェース」だと認識してほしい。
君たちが書くその一行のクエリが、数億のトラフィックを支えることになる。その重みを感じながら、設計・実装にあたってほしい。期待している。
コメント