【入門編】 STORING句によるカバリングインデックス – Cloud Spanner

やあ。Cloud Spannerという、とてつもなく強力で、同時に扱いには少しだけ「コツ」がいる相棒の世界へようこそ。

今日は、Spannerのパフォーマンスを劇的に向上させる魔法のテクニック、「STORING句を使ったカバリングインデックス」について話をしよう。

初心者向けに書くけれど、表面的な手順だけをなぞるようなことはしない。なぜこれが速いのか、その「本質」を君の脳裏に焼き付けてほしい。準備はいいかな？

—

まずは、「図書館」を想像してみてほしい。君が「『エンジニアの魂』というタイトルの本はどこにある？」と司書さんに尋ねる。

1. インデックス（索引）: 司書さんはまず索引カードを見て、「あ、それは棚番号10番ですね」と教えてくれる。
2. テーブル本体（本棚）: 君は棚番号10番まで歩いていき、実際にその本を手に取る。

この「索引を見てから、本棚まで移動する」という往復作業が、データベースの世界では「インデックス検索後のテーブル読み取り」にあたる。データ量が少ないうちはいい。でも、もし本が1億冊あったら？その往復だけで時間は溶けていくよね。

ここで登場するのが「カバリングインデックス（Covering Index）」だ。
先ほどの図書館でいえば、「索引カードの中に、本のタイトルだけでなく、本の内容の『要約』まで全部書いてある状態」を指す。

これなら、本棚まで歩いていく必要はないよね。索引を見た瞬間に、欲しい情報がすべて手に入る。これが、データベースにおける「爆速」の正体だ。

Cloud Spannerでこれを実現するのが `STORING` 句だ。

Spannerのインデックスは、通常「キー（検索の入り口）」しか持たない。そこに `STORING` を使うと、指定した列のデータをインデックスの中に「コピーして持ち込む」ことができるんだ。

例えば、ユーザーの「メールアドレス」から「名前」を検索する機能を作るとする。

— 通常のインデックス：メールアドレスをキーにするだけ
CREATE INDEX UsersByEmail ON Users(Email);

— カバリングインデックス：Emailをキーにして、Nameを「持参」させる
CREATE INDEX UsersByEmailStoring ON Users(Email) STORING (Name);

こうすると、`SELECT Name FROM Users WHERE Email = ‘…’` というクエリを投げたとき、Spannerはわざわざ `Users` テーブル本体を見に行かない。`UsersByEmailStoring` という「要約リスト」だけで完結するんだ。

エンジニアがなぜこの手法を愛するか。理由はシンプルで、「物理的なI/O（読み取り）を極限まで減らせるから」だ。

テーブル本体へのアクセス不要: ディスクへの往復回数が減れば、レイテンシは劇的に改善する。
計算リソースの節約: テーブル全体を読み込む必要がないため、CPU負荷も下がる。
スケールの恩恵: Spannerは分散データベースだ。データが複数のサーバーに分かれていても、インデックスがカバーしていれば「一箇所」で完結する確率が高くなる。

—

ここまで読んで「じゃあ、全部の列をSTORINGに入れれば最強じゃん！」と思った君、鋭いね。でも、それはNGだ。

ストレージ容量の増加: インデックスの中にデータをコピーするわけだから、当然その分だけディスクを消費する。
書き込み速度の低下: データを保存するとき、「テーブル」と「インデックス」の両方を更新しなきゃいけない。インデックスが多すぎると、書き込みのたびにSpannerの仕事が増えてしまうんだ。

「よく使う検索条件」かつ「頻繁に取得する列」に絞って使う。これが、伝説のエンジニアたちが守っている鉄則だよ。

—

今回のポイントを整理しよう。

1. インデックスは「地図」。テーブル本体は「目的地」。
2. STORINGは「地図に目的地の中身を書いておくこと」。移動の手間を省く。
3. 多用は禁物。容量と書き込みコストのバランスを考えること。

これで、Cloud Spannerのパフォーマンス設計における「重要な武器」を一つ手に入れたことになる。

データベースを設計するときは、常に「Spannerがどうデータを拾いに行くか」を想像してみてほしい。その想像力が、君を一流のエンジニアへと押し上げてくれるはずだ。

次は、実際に君のプロジェクトで「どの列をSTORINGすべきか」を考えてみてくれ。もし迷ったら、またいつでも相談してほしい。応援しているよ。