「またインデックスの設計で悩んでるのか？まあ、PostgreSQLのチューニングは奥が深いからな。今日はちょっと面白い武器を紹介してやるよ。」
現場でパフォーマンス改善をしていると、B-treeインデックスだけじゃどうにもならない壁にぶつかることがあるだろ？特に、「複数のカラムを組み合わせた条件での検索」や「巨大なデータセットの中での存在確認」なんてのは、インデックスサイズが肥大化しすぎて、かえってクエリが遅くなるなんてことも珍しくない。
そんな時に一度思い出してほしいのが、`bloom` インデックスだ。
Bloomインデックスって何者だ？
一言で言うと、「確率論的に『ここにはデータがない』と断言するフィルタ」だ。
正確には「ブルームフィルタ」というデータ構造をPostgreSQLに持ち込んだものなんだけど、これの面白いところは「データが存在する可能性があるか？」を非常に軽量なメモリ消費で判定できる点にあるんだ。
B-treeみたいに「値の順序」を保持するわけじゃないから、範囲検索（`>` や `<`）には全く向かない。その代わり、複数のカラムを組み合わせた等価検索（`=`, `IN`）において、驚異的な省スペース性と検索効率を発揮するんだ。
なぜわざわざ使うのか？
B-treeで複数列のインデックスを張ると、インデックスサイズが凄まじいことになって、ディスクI/Oがボトルネックになりがちだろ？
Bloomインデックスは、ハッシュ値を使ってビット配列にマッピングするから、インデックス自体がめちゃくちゃ小さい。つまり、「ディスクから読み込むデータ量」を極限まで減らせるんだ。
もちろん、たまに「偽陽性（データがないのに、あると判定される）」が起きる。でも、PostgreSQLがその後にちゃんとテーブル本体をチェックしてくれるから、結果が間違えることはない。要するに、「本番のチェックをする前に、いらないデータを足切りする優秀な門番」を雇うようなもんだと思えばいい。
実装してみよう
こいつを使うには `contrib` モジュールが必要だ。まずは拡張機能を有効にする。
CREATE EXTENSION bloom;
例えば、ユーザーの属性情報が大量にあるテーブルで、`category_id`, `status`, `user_type` の3つを組み合わせて頻繁に検索するようなケースを想像してみてくれ。
CREATE INDEX idx_user_bloom ON users
USING bloom (category_id, status, user_type)
WITH (length = 80, col1 = 2, col2 = 2, col3 = 4);
ここで出てくる `length` や `colN` というパラメータが肝だ。
- length: ビット配列の長さ（デフォルトは80。大きくするほど偽陽性が減るが、サイズが増える）。
- colN: 各列に割り当てるハッシュ関数の数。
ここがチューニングの腕の見せ所なんだ。業務で使うなら、まずはデフォルトで試して、`EXPLAIN ANALYZE` を叩きながら、ディスク読み込みが減っているかを確認する。これが鉄則だぞ。
気をつけるべき「罠」
いいことばかりじゃない。実務で使うなら、以下の3点だけは頭に叩き込んでおけ。
1. 範囲検索には使えない: `WHERE category_id > 10` なんてクエリには無力だ。あくまで等価検索専用だと思ってくれ。
2. 更新コスト: インデックスを更新するたびにハッシュ計算が走るから、書き込みが激しいテーブルだとオーバーヘッドが無視できない。読み取り専用に近い「分析系」や「履歴系」のテーブルで真価を発揮するタイプだな。
3. パラメータ設計: `length` を適当に決めると、精度がガタ落ちする。データ量とクエリの頻度を見ながら、実験的に数値を振ってみる粘り強さが大事だ。
先輩からのアドバイス
「どんなインデックスが最強か？」なんて問いに答えはない。B-treeは万能選手だけど、Bloomインデックスは特定の条件下で「魔法の杖」になる。
もし今、インデックスのサイズが膨れ上がってサーバーのメモリを圧迫しているなら、一度 `bloom` で軽量化できないか検討してみてくれ。「インデックスを減らして、検索を速くする」なんていう、エンジニア冥利に尽きる最適化ができるかもしれないぞ。
何か詰まったらまた聞きに来い。一緒に実行計画を見ながら最適解を探そうじゃないか。
コメント