こんにちは。Cloud Spannerの世界へようこそ。
大規模なデータを扱うシステムの「心臓部」を任されるこのデータベースは、一見とっつきにくそうに見えるかもしれません。でも、仕組みさえ掴んでしまえば、これほど頼もしい相棒はいませんよ。
今日は、Spannerを使いこなすエンジニアなら必ず押さえておきたい「NULL_FILTERED（ヌル・フィルタード）」という、ちょっと賢いインデックスのお話をしましょう。
—
「インデックス」って、結局なに？
まずは基本から。図書館を想像してみてください。
本が何万冊とある中で、特定のタイトルを探すとき、あなたは本棚を端から端まで探し回りますか？ そんなことしたら日が暮れてしまいますよね。
そこで使うのが「索引（インデックス）」です。「あいうえお順」に並んだカードがあれば、一瞬で目的の本の場所にたどり着けます。
Spannerも同じです。データが膨大になればなるほど、インデックスは「検索の速さ」を左右する命綱になります。
—
「NULL」という存在の厄介さ
さて、ここで少し厄介なのが「NULL（ヌル）」という存在です。これは「データが入っていない状態」のこと。
例えば、「ユーザーのニックネーム」を登録するシステムがあるとします。
- ニックネームがある人：100万人
- ニックネームが未設定の人：50万人
このとき、ニックネームにインデックスを貼ると、Spannerは「未設定（NULL）の人たち」まで律儀に索引カードに書き込んでしまいます。
でも、よく考えてみてください。ニックネームで検索する人は、「ニックネームを持っている人」を探しているはずですよね。「ニックネームがない人」をわざわざ検索することはまずありません。
この「使われないはずのNULLのためのインデックス」は、ただの「重り」になってしまいます。
—
NULL_FILTERED：賢い「選別」の技術
そこで登場するのが `NULL_FILTERED` というオプションです。
これは、「NULLのデータは索引カードに載せないで！」と指示する魔法の言葉です。
- メリット1：インデックスサイズが激減する
使われないデータの分まで記録しなくて済むので、インデックスのサイズがスリムになります。
- メリット2：検索性能が向上する
索引カードの枚数が減れば、それだけ目的のデータを探すのが速くなります。
- メリット3：コストの削減
Spannerは容量に応じた課金がされるので、無駄なデータを削ることは、そのままコストダウンに直結します。
—
実践：どうやって書くの？
実際にテーブルを作る時のコードを見てみましょう。
— ニックネーム(nickname)にNULL_FILTEREDインデックスを貼る例
CREATE INDEX UsersByNickname ON Users(nickname)
— ここがポイント！NULLの値はインデックスから除外するよう指示します
NULL_FILTERED;
これだけで、Spannerは「お、ニックネームが空っぽのやつは索引に載せなくていいんだな」と理解し、効率的に動いてくれるようになります。
—
先輩エンジニアからのアドバイス
この `NULL_FILTERED` を使うべきかどうかの判断基準はシンプルです。
「検索条件として、NULLを探すことはありますか？」
もし、システム上「ニックネームが未設定の人」を抽出する機能が一切ないのであれば、迷わず `NULL_FILTERED` を使いましょう。逆に、もしNULLの状態を頻繁に検索するのであれば、このオプションは使ってはいけません（使うと検索できなくなってしまいますからね）。
—
ここをクリアすれば、もう中級者！
どうでしょう。「インデックスは全部貼ればいい」というわけではなく、「何が必要で、何が無駄か」を見極めること。これがCloud Spannerという巨大なシステムを軽やかに操るための第一歩です。
この「NULL_FILTERED」の考え方が身につけば、あなたはもう、ただの利用者から「設計者」の視点に一歩近づいています。
Spannerは、あなたの設計次第でどこまでも速く、効率的になります。またわからないことがあれば、いつでも聞きに来てくださいね。あなたの挑戦を応援しています！
コメント