こんにちは。Cloud Spannerの世界へようこそ。
分散データベースの最高峰であり、かつては「魔法のような技術」と言われたSpannerを学ぼうとするあなたのその好奇心、素晴らしいですね。今日は、Spannerのパフォーマンスを左右する最も重要なパーツの一つ、「セカンダリインデックス」という武器について、専門用語を極力排して解説していきます。
難しく考える必要はありません。一緒に、図書館の仕組みを想像しながら紐解いていきましょう。
—
1. セカンダリインデックスは「図書館の索引カード」だ
想像してみてください。あなたは巨大な図書館で、数百万冊の中から「特定の著者が書いた本」を探しています。
本の並び順が「出版日順」だったらどうでしょう？ 著者名で探すには、端から一冊ずつ確認していくしかありません。これでは日が暮れてしまいますよね。そこで役立つのが「著者名順に並んだ索引カード（インデックス）」です。
Cloud Spannerでも同じです。データは基本的に「主キー（本の背表紙の番号のようなもの）」で整理されていますが、それ以外の条件（例えば「メールアドレスで検索したい」「注文日で絞り込みたい」）でデータを頻繁に探すなら、専用の索引を作っておくべきです。それが「セカンダリインデックス」です。
2. 「STORING句」は最強のショートカット
インデックスを作ると、検索は爆速になります。しかし、一つだけ注意点があります。
索引カード（インデックス）を見て「この本だ！」と分かっても、書棚に戻って本体を取りに行かなければ、中身（詳細なデータ）は読めませんよね。Spannerも同じで、インデックスで場所を特定した後、本体のデータを読みに行く「2度手間」が発生することがあります。
これを解消するのが `STORING` 句 です。
これは、索引カードの端っこに、よく使う「中身のメモ」をあらかじめ書き写しておくようなものです。
— ユーザーテーブルから、メールアドレスで検索するためのインデックスを作成
— STORING句を使って、よく使う「名前」を一緒に持ち歩く設定です
CREATE INDEX UsersByEmail ON Users (Email)
STORING (Name);
こうすることで、検索時に本体データを見に行く必要がなくなり、インデックスだけで検索が完結します（これをカバリングインデックスと呼びます）。 これが性能を劇的に引き上げる、プロの知恵です。
3. NULL値との付き合い方
現実の世界でも「データがまだ決まっていない（NULL）」ことはよくあります。Spannerのインデックスにおいて、NULL値は「存在しないもの」として扱われることが多いです。
例えば、`Email` にインデックスを貼った場合、`Email` が空（NULL）の人は、その索引カードには載りません。もし「まだメールアドレスを登録していないユーザーを探したい」という検索を頻繁に行うなら、NULL値も含めたインデックス戦略が必要になります。
「すべてをインデックスに載せる必要はない」と割り切るのも、賢いエンジニアの選択ですよ。
—
まとめ：ここさえ押さえれば大丈夫！
今日伝えたかった「Spannerを使いこなすための3つの心構え」を整理します。
1. 検索条件はインデックスに任せる: 全件走査（フルスキャン）は、図書館で一冊ずつ棚を調べるようなもの。インデックスという「索引」を賢く作りましょう。
2. `STORING` 句で「2度手間」を減らす: 検索結果として表示したい項目は、`STORING` でインデックスに同伴させましょう。これが高速化の秘訣です。
3. インデックスは「必要な分だけ」: インデックスは検索を速くしますが、データを書き込むときには「索引カードも更新しなきゃ！」と手間が増えます。バランスが大事です。
—
いかがでしたか？
「検索が遅い」と悩んだとき、まずは「どの索引カードがあれば解決するか？」を考えるだけで、あなたのコードは劇的に進化します。
Cloud Spannerは、ただのデータベースではありません。正しく設計すれば、世界中のどこからアクセスしても一瞬で答えを返す、あなたの最強のパートナーになります。
ここをクリアしたあなたは、もう立派なSpanner使いの入り口に立っています。自信を持って、次のステップへ進んでくださいね！
コメント