【実務・中級編】 Bloomフィルタインデックス – PostgreSQL

なぜ、いつものB-treeインデックスだけじゃ物足りないのか？

「インデックスを貼れば速くなる」……これはデータベースエンジニアが最初に習う鉄則ですよね。でも、現場で泥臭いチューニングをしていると、必ずどこかで「インデックスの肥大化」という壁にぶつかります。

特に、「特定のカラムの組み合わせで検索することが多い」というケース。全部のカラムに個別インデックスを貼るとインデックスサイズが膨れ上がり、更新時のオーバーヘッドでパフォーマンスがガタ落ちする。かといって複合インデックスを作ろうにも、クエリのパターンが多すぎて追いつかない。

そんなとき、僕が「隠し玉」として検討するのがBloomフィルタインデックスです。

今日は、PostgreSQLの拡張モジュール`pg_bloom`を使って、ストレージを節約しながら検索性能を維持する、ちょっとニッチで強力な武器について話をしましょう。

—

Bloomフィルタって結局なんなの？

一言で言うと、「あるデータが存在する可能性があるか、絶対に存在しないか」を高速に判定する確率的なデータ構造です。

B-treeが「値がどこにあるか」を正確に指し示す地図だとすれば、Bloomフィルタは「このエリアには目当てのものがないから、わざわざ見に行く必要はないよ」と教えてくれる看板みたいなもの。

PostgreSQLの`pg_bloom`を使うと、複数のカラムを一つのインデックスにギュッと圧縮して詰め込めます。その代わり、「誤陽性（本当はないのに『あるかも』と判定されること）」が発生する可能性がありますが、そこはPostgreSQL側がちゃんとテーブルを再チェックしてくれるので、正確性は担保されます。ご安心を。

—

実践：pg_bloomでインデックスを作る

まずは拡張を有効にしましょう。

CREATE EXTENSION bloom;

例えば、ユーザーの属性テーブルで `city`, `gender`, `status` の3つを頻繁に組み合わせて検索するようなケース。普通なら3つのカラムに対してあれこれインデックスを貼るところですが、Bloomならこう書けます。

CREATE INDEX idx_user_bloom ON users
USING bloom (city, gender, status)
WITH (col1 = 2, col2 = 2, col3 = 4);

ここで大事な「パラメータ」の話

`col1`, `col2`, `col3` という数字が見えますね。これが各カラムの「有意性」を指定するパラメータです。

値が大きいほど： 誤陽性が減る（＝検索が正確になる）が、インデックスサイズは大きくなる。
値が小さいほど： インデックスは極小になるが、誤陽性が増えてテーブルアクセスが増える。

ここはトレードオフです。僕は最初、とりあえずデフォルトのまま作って、`EXPLAIN ANALYZE` を叩きながら調整していきます。「インデックスは小さくしたいけど、テーブルを読みに行く回数は増やしたくない」という瀬戸際を狙うのが、腕の見せ所ですね。

—

Bloomフィルタが真価を発揮する瞬間

僕がこのインデックスを推すのは、以下のようなケースです。

1. カラムが多い「多次元検索」:
検索条件が毎回バラバラで、すべての組み合わせにインデックスを貼るのが現実的でないとき。
2. インデックスサイズを抑えたい:
メモリに乗らない巨大なインデックスは、結局ディスクI/Oを発生させて遅くなります。「インデックスそのものを小さくしてメモリに収める」という戦略なら、Bloomは最強の選択肢の一つです。
3. 等価比較（=）がメイン:
残念ながら、Bloomは「範囲検索（> や <）」には使えません。`WHERE city = 'Tokyo' AND gender = 'M'` のような、ビシッと値を決めるクエリに特化しています。 ---

先輩からのアドバイス：過信は禁物！

ここまで褒めてきましたが、注意点もあります。

更新（UPDATE/INSERT）には弱い:

Bloomフィルタの構造上、一度作ると中身を書き換えるのが苦手です。更新頻度が非常に高いテーブルだと、インデックスの再構築コストが無視できなくなることがあります。

等価検索以外はスルー:

繰り返しになりますが、`BETWEEN` や `LIKE` 検索には全く効きません。「全部のクエリが速くなる魔法の杖」ではないことを忘れないでください。

最後に

Bloomフィルタは、データベースの「物理設計」を少しだけハックするような手法です。すべての現場で使えるわけではありませんが、「インデックスが重すぎて困っている」「複合検索が多すぎてインデックスの海に溺れている」というときは、ぜひ試してみてください。

「インデックスは、貼れば貼るほどいいわけじゃない」。そう思えるようになったら、もう一人前のデータベースエンジニアですよ。

また何か詰まったら聞きに来てください。現場からは以上です！