【入門編】スキーマのバージョン管理 – Cloud Spanner

やあ。Cloud Spannerという、とてつもなくパワフルで、かつ少しだけ気難しい「相棒」の世界へようこそ。

君がいま向き合おうとしているSpannerは、世界中の巨大なシステムを支えるいわば「究極のデータベース」だ。今日は、その中でも特に頭を悩ませがちな「スキーマのバージョン管理（データベースの設計図をどう進化させるか）」について、専門用語を極力排して、君の心にスッと入るように話そうと思う。

これをマスターすれば、君はもうSpanner運用の第一歩を力強く踏み出したことになる。準備はいいかい？

—

データベースを「巨大な図書館」だと想像してみてほしい。
Spannerのスキーマ（設計図）を変えるということは、「開館中に図書館の棚の配置を変える」ようなものだ。

通常、図書館の配置を変えるなら「一度閉館して、本を全部運び出して…」と大騒ぎになるよね。でも、Spannerは「開館したまま、お客さんの邪魔をせず、いつの間にか棚が新しくなっている」という神業をやってのけるんだ。

システムは生き物だ。最初は「名前」と「住所」さえあれば良かった顧客リストも、半年後には「SNSアカウント」や「ポイント残高」が必要になる。

この時、設計図を書き換えるたびに「えーっと、前は何を変えたんだっけ？」とメモがバラバラだと、後で地獄を見る。だからこそ、「設計図がどう変わってきたか」という歴史（バージョン管理）を記録しておくことが、プロのエンジニアの嗜みなんだ。

Spannerで設計図を変えるとき、最も大切なのは「一度に欲張らないこと」だ。

例えば、「新しい棚を追加して、そこに本を並べる」という作業を一度にやろうとすると、エラーが起きた時に何が原因か分からなくなる。だから、こうするんだ。

1. 「新しい空の棚を置く」（列の追加）
2. 「必要なら古い棚からデータをコピーする」（データの移行）
3. 「古い棚を撤去する」（不要な列の削除）

これを一つずつ、確実に進める。これが、世界最高峰のエンジニアたちが実践している「安全なマイグレーション（移行）」の鉄則だよ。

「どうやって管理すればいいの？」と迷うなら、まずは「設計図をコードとして保存する」ことから始めよう。

手作業でSpannerの管理画面をポチポチいじるのは卒業だ。設計図をテキストファイル（`.sql`ファイル）にして、Gitのようなツールで管理するんだ。

例：`v1_initial_schema.sql`

— 最初はシンプルにこれだけ
CREATE TABLE Users (
UserId INT64 NOT NULL,
UserName STRING(MAX)
) PRIMARY KEY (UserId);

例：`v2_add_email.sql`

— 後からメールアドレスを追加する場合も、こうしてファイルを分ける
ALTER TABLE Users ADD COLUMN Email STRING(256);

こうやって「いつ、誰が、何を変えたか」というファイルを積み重ねていけば、もし何かあった時でも「v1の状態に戻そう」という判断がすぐにできる。これが「バージョン管理」の正体さ。

初心者ほど、「設計図を変えるときにシステムが止まったらどうしよう」と不安になる。でも大丈夫。Spannerは「オンライン・スキーマ変更」という強力な武器を持っていて、数億件のデータがあっても、裏側で静かに、かつ高速に棚を並び替えてくれる。

君がやるべきことは、「変更する前に、小さな環境でその手順をテストすること」。これさえ守れば、Spannerは君の最強の味方であり続けてくれるよ。

—

1. 設計図の変更は「小さなステップ」に分ける。（いきなり全部変えない！）
2. 設計図の変更履歴は、コードとして保存する。（手作業は禁止！）
3. まずはテスト環境で、同じ手順を試す。（失敗してもいい場所を作っておく）

どうかな？難しく考えすぎていたかもしれないけれど、結局は「丁寧な整理整頓」と同じなんだ。

君がこれから作るシステムが、Cloud Spannerの上でしなやかに、力強く育っていくことを楽しみにしているよ。また分からないことがあったら、いつでも聞きに来て。応援しているぞ！