やあ。Cloud Spannerの世界へようこそ。
世界中のエンジニアが「究極のデータベース」と呼ぶこの怪物も、仕組みさえ理解してしまえば、実はとても頼もしい相棒になるんだ。
今日は、Spannerを使いこなすための「登竜門」、セカンダリインデックスについて話そう。難しい理屈は一旦置いて、まずは君の身近なものに例えてみるね。
—
インデックスは「本の巻末索引」と同じ
君が分厚い辞書で「Spanner」という言葉の意味を調べたいとき、どうする？
最初から順番にページをめくる人はいないよね。巻末の「さくいん」を開いて、「す」の項目を探すはずだ。
データベースにおけるインデックスも全く同じ役割だよ。
主キー（データの住所のようなもの）以外の条件で検索したいとき、インデックスがないと、データベースは全ページを端から端までめくって探すことになる。これはデータが増えれば増えるほど絶望的な時間がかかるんだ。
Cloud Spannerのセカンダリインデックスは、この「辞書の索引」を自動で作ってくれる魔法のような機能さ。
—
なぜ「セカンダリ」と呼ぶのか？
まず、Spannerには主キー（Primary Key）という「絶対的な住所」がある。データはこの主キー順にきれいに並んで保存されているんだ。これを「テーブルそのもの」としよう。
その横に、特定の列（例えば「ユーザー名」や「メールアドレス」）だけを抜き出して、別の並び順で整理し直したリストを作る。これがセカンダリインデックスだ。
「2番目の並び順」を作るから、セカンダリと呼ぶんだよ。
—
NULL値とインデックスの「意外な関係」
さて、ここからが少しだけ本質的な話だ。
初心者が陥りやすい罠がある。それは「NULL（空っぽ）」の扱いさ。
実は、Cloud Spannerのインデックスには「NULL値は保存されない」という特性がある。
- 例え話： クラスの名簿で「身長順」の索引を作るとき、身長を測っていない（NULLの）生徒をそのリストに載せる必要はあるかな？ 載せないよね。それと同じで、Spannerも「値が入っていないデータ」をインデックスに載せると無駄に容量を食うだけだから、あえて無視するんだ。
もし「NULLのデータも含めて検索したい！」という要件があるなら、インデックスだけでは解決できない場合がある。この「NULLの省略」という仕様を知っているだけで、君は他のエンジニアと一歩差がつくよ。
—
インデックス作成のコード（実践編）
実際にSpannerでインデックスを作るのは、驚くほど簡単だ。
例えば、「Users」というテーブルの「Email」列を使って検索を速くしたい場合、こんなDDLを書く。
— UsersテーブルのEmail列にインデックスを作成する
CREATE INDEX UsersByEmail ON Users(Email);
— これで、以下のクエリが爆速になる
— SELECT FROM Users WHERE Email = ‘example@gmail.com’;
もし、インデックスに別の情報も持たせたい（これを「カバーリングインデックス」と言うんだ）なら、`STORING`句を使うんだ。
— Emailで検索した時に、一緒に「名前」も取得したい場合
CREATE INDEX UsersByEmail ON Users(Email) STORING(UserName);
こうすると、わざわざ元のテーブルまでデータを見に行かなくても、インデックスの索引だけで「メールアドレス」と「名前」の両方が手に入る。これがSpannerのパフォーマンスを極限まで引き出すための「プロの技」さ。
—
最後に：先輩からのアドバイス
インデックスは便利だけど、「作れば作るほどいい」というわけじゃないんだ。
索引を作りすぎると、新しいデータを追加するたびに、その全ての索引を更新しなきゃいけない。本を1冊出すたびに、100種類の索引を書き換える作家を想像してみてほしい。本を書く（データを保存する）速度が極端に落ちるだろう？
1. 本当によく使う検索項目に絞る
2. NULLの扱いを意識する
3. `STORING`を使って検索効率を最大化する
この3つさえ押さえておけば、君はもうCloud Spannerのインデックスを使いこなしていると言っても過言じゃない。
最初は難しく感じるかもしれないけれど、Spannerは君が書いたコードに応えてくれる、とても素直なデータベースだよ。焦らず、一歩ずつ進んでいこう。
また何か壁にぶつかったら、いつでも聞きに来て。君のエンジニアとしての成長を、心から応援しているよ。
コメント