やあ。Cloud Spannerという、少し癖があるけれど最高に頼りになる「相棒」について学びに来たんだね。素晴らしい選択だ。
今日は、Spannerを使っていると必ずぶつかる「インデックスのバックフィル（後付け）」という儀式について話をしよう。ドキュメントには「非同期で裏で動くよ」としか書かれていないことが多いけれど、その裏側にあるドラマを理解すると、君のエンジニアとしての視座はグッと高まるはずだ。
—
「図書館の蔵書」で例えるインデックス
まず、Cloud Spannerを「とてつもなく巨大な図書館」だと想像してほしい。
君は今、何億冊もの本（データ）が並ぶ図書館の館長だ。最初は「本のタイトル」だけで検索できるようにしていたけれど、利用者が増えてきて「著者名」でも検索したくなったとしよう。
ここでやるのが「インデックスの追加」だ。
もし普通のデータベースなら、「今から全員、本棚を整理して著者名リストを作れ！」と号令をかけて、その作業が終わるまで図書館を閉館（停止）しなきゃいけない。でも、Cloud Spannerは違う。
Cloud Spannerの魔法：バックフィル（非同期処理）
Spannerは、「図書館を営業したまま、裏でこっそり作業員を動かしてリストを作る」という離れ業をやってのける。これが「バックフィル」だ。
1. 指示を出す: 「著者名のインデックスを追加してくれ」と命令する。
2. 裏方作業: スパナーの内部にある数千、数万の小さな作業員（スプリット）たちが、自分たちが担当するエリアの本をコツコツと読み込み、著者名リストを追記していく。
3. 普段通り: その間も、利用者は本を借りたり返したりできる。Spannerは新しい本が入ってきたら、それも忘れずにリストに書き加えるんだ。
これが「非同期処理」の正体だよ。システムを止めないために、Spannerは裏で実に賢く立ち回っているんだ。
—
「完了までどれくらいかかるの？」という問いへの答え
よく「バックフィルはどれくらいで終わりますか？」と聞かれる。僕の答えはいつもこうだ。「それは、君がどれだけ急いでいるか、そしてどれだけ図書館が混んでいるかによるよ」。
これにはいくつかの要因があるんだ：
- データの量: 当たり前だけど、100万冊より1億冊の方が時間がかかる。
- CPUの負荷: 図書館が超満員で、みんなが本を借りるのに必死な時、作業員たちは「今は忙しいから少し待とう」とペースを落とす。Spannerは「検索」というお客様の体験を最優先するからね。
- スプリットの数: Spannerはデータを細かく分割（スプリット）して管理している。この分割が適切なら、多くの作業員が並行して動けるから、爆速で終わる。
完了を確認するコード（Spannerの今の状態を覗く）
Spannerは「今、何％くらい進んだかな？」と確認する手段をちゃんと用意している。Google Cloudのコンソールでも見れるけれど、裏側ではこんな情報を参照しているんだ。
— Spannerのシステムテーブルを覗いて、バックフィルの進捗を確認する
SELECT
TABLE_NAME,
INDEX_NAME,
INDEX_STATE
FROM
SPANNER_SYS.INDEX_STATS
WHERE
INDEX_STATE = ‘BUILDING’; — ‘BUILDING’ は「今まさに作ってる最中」のサイン
このクエリの結果、`INDEX_STATE` が `READER_READY` に変わった時、君の新しいインデックスは晴れて「いつでも使える状態」になる。
—
先輩から君へのアドバイス
バックフィルが走っている間、君のシステムは裏で少しだけCPUを消費している。だから、「めちゃくちゃ忙しいピーク時間帯」に重いインデックスを大量に追加するのは避けるのが、ベテランの流儀だ。
「バックフィルは、魔法のように見えるけれど、裏側では一生懸命働いている作業員がいる」。この感覚を持っていれば、君はもうSpannerを単なるストレージではなく、ひとつの生き物として扱えるようになっているはずだ。
ここを理解できれば、Cloud Spannerの基本はバッチリマスターできたと言ってもいい。もし次に「インデックスを貼るのが怖い」と思ったら、今日のこの図書館の話を思い出してほしい。
さあ、恐れずに次の挑戦へ進もう。何かあればいつでも聞いてくれ。応援しているよ。
コメント