【テクニカル・上級編】 Bloomインデックス – PostgreSQL

PostgreSQLの「隠し玉」、Bloomインデックスを使いこなす。その設計思想と罠。

PostgreSQLを長く触っていると、「特定の列の組み合わせで検索したいけど、インデックスが肥大化しすぎて辛い」という局面に必ず出くわすはずだ。B-treeを複数列で貼れば当然サイズは膨れ上がるし、かといってビットマップスキャンに頼るのもクエリの複雑性やカーディナリティ次第で命取りになる。

そんな時、ふと思い出してほしいのが `bloom` 拡張だ。知る人ぞ知るこのインデックス、実はかなり尖った性能をしている。今日は、こいつの内部構造と、現場で「ハマらない」ための勘所について、少し深掘りしてみたいと思う。

—

Bloomインデックスの本質：確率論との付き合い方

Bloomインデックスの正体は、その名の通り「ブルームフィルタ」をインデックス構造として採用したものだ。B-treeのように「値そのもの」をソートして保持するのではなく、複数のハッシュ関数を用いて、値を「存在フラグの集合」にマッピングする。

この構造がもたらす最大の恩恵は、圧倒的な省スペース性だ。

例えば、5列の組み合わせで検索を行いたい場合、B-treeならキーの数だけインデックスが巨大化するが、Bloomなら指定した長さのシグネチャ（署名）に全ての列のハッシュ値を押し込める。もちろん、これは「確率的なデータ構造」だ。つまり、「データが存在するかもしれない（Maybe）」というヒントとして機能し、確実な場所を指し示すわけではない。

この「Maybe」という特性こそが、Bloomを理解する鍵になる。

なぜ「多列検索」で輝くのか

Bloomが最も輝くのは、以下のようなケースだ。

カーディナリティが中程度以上の列が複数ある。
「AND」条件で絞り込むクエリが支配的。
ストレージ容量やメモリキャッシュ（shared_buffers）を節約したい。

B-treeと違って、Bloomは「列の順序」をあまり気にしなくていい。B-treeは左側の列から順に絞り込む必要があるが、Bloomは「指定した全列のハッシュをビット列に落とし込む」ため、どの列をどう組み合わせて指定しても、フィルタリングの精度（偽陽性率）は大きく変わらない。これが、アドホックな検索が多い分析系ワークロードで重宝される理由だ。

パフォーマンストラブルシューティング：設計の罠

さて、ここからは少し辛口な話をしよう。Bloomを導入して「思ったより速くない」と嘆くエンジニアのほとんどは、`col1, col2…` の設定と `length` パラメータを適当に決めている。

1. 偽陽性率（False Positive）との戦い

Bloomはインデックスが「ある」と判定しても、実際にはデータがない場合がある（偽陽性）。この時、データベースはヒープ領域（実テーブル）までわざわざデータを見に行くことになる。これが多発すると、インデックスを貼る前よりもI/O負荷が跳ね上がる。

`length`（シグネチャの長さ）をケチりすぎると、この偽陽性が爆発する。逆に長すぎればインデックスが肥大化し、メモリ効率が悪くなる。理想的なシグネチャ長は、保持するレコード数と、許容する偽陽性率から計算すべきだが、現場ではまず `length=80` くらいから始めて、pg_stat_user_indexesを眺めながらチューニングする、という泥臭いアプローチが結局一番速い。

2. 更新負荷は無視できない

BloomはB-treeよりも更新コストが重い場合がある。複数のハッシュ関数を計算し、ビット配列を更新するため、高頻度な `UPDATE/INSERT` が走るテーブルに貼ると、WALの書き込み量とCPU使用率が如実に跳ね上がる。参照専用（Read-only）に近いテーブルか、バッチ処理での追記がメインのテーブルでこそ、真価を発揮するインデックスだと言える。

最後に：使い所を見極めるプロの眼

Bloomインデックスは、銀の弾丸ではない。しかし、B-treeの限界を感じているエンジニアにとって、これほど強力なカードはそう多くない。

データが巨大すぎてB-treeがメモリに乗り切らない時。
特定の列の組み合わせで高速に「除外」したい時。

これらに当てはまるなら、ぜひ一度検証環境で `CREATE EXTENSION bloom;` を叩いてみてほしい。

ただし、「Bloomを貼ったから安心」ではない。 インデックスを貼った後に `EXPLAIN ANALYZE` を叩き、`Recheck Cond` が多発していないか、ヒープへのアクセスが想定以上に走っていないかを必ず確認する。結局、データベースエンジニアの仕事は、カタログスペックを信じることではなく、現場のデータとクエリの挙動を観察し続けることにあるのだから。

さて、あなたの環境のクエリプランナは、今日も健全に動いているだろうか。