巨大データとの付き合い方：BRINインデックスという「賢い妥協」
PostgreSQLを長年触っていると、必ずと言っていいほど「テーブルサイズがテラバイト級に達した時」の壁にぶつかります。B-treeインデックスは確かに万能ですが、巨大なテーブルに対してインデックスを張ると、インデックスサイズ自体がメモリを圧迫し、WALの書き込み量も肥大化する。まさにインデックスのためのインデックスメンテナンスに追われる日々です。
そんな時、僕らが最後に頼るのが「BRIN (Block Range Index)」です。今回は、この少しクセのある、しかし刺さる場所には強烈に刺さるインデックスについて、少し深いところまで掘り下げてみましょう。
—
BRINは「インデックス」というより「要約」である
まず誤解を解いておくと、BRINをB-treeの代替品だと思ってはいけません。B-treeが各行のポインタを保持する「詳細な地図」だとすれば、BRINは「このエリアにはこんな値が入っている」という「大まかな看板」です。
BRINのアーキテクチャの肝は「物理的な相関性（Physical Correlation）」です。
PostgreSQLは、テーブルを「ページ（ブロック）」の集合体として管理しています。BRINは、物理的に隣り合う複数のページを一つの「範囲（Range）」としてまとめ、その範囲内での「最小値」と「最大値」だけをメモリに保持します。
クエリが実行されると、BRINはこの「最小値・最大値」を見て、「この範囲には探している値が含まれている可能性があるか？」を判定します。もし無ければ、その数千ページ分を一気にスキップできる。これがBRINの圧倒的な軽量さの秘密です。
なぜ「相関性」が全てなのか
BRINの性能は、「データの物理的な並び順」と「インデックス対象の列の値」の相関関係に100%依存します。
例えば、`created_at` のように、時間が経つにつれて値が単調増加するカラム。これにBRINを張ると、各範囲の最小値・最大値は非常に綺麗に分かれます。結果、検索効率は驚くほど高くなります。
逆に、ランダムなIDや更新が頻繁に発生するカラムにBRINを張るとどうなるか。全ての範囲で「最小値はほぼ0、最大値はほぼ最大」となってしまい、結局すべての範囲をスキャンすることになります。こうなると、BRINは単なるオーバーヘッドでしかありません。
運用でハマるポイントとトラブルシューティング
BRINを使いこなす上で、現場でよく遭遇する落とし穴をいくつか共有しておきます。
- `pages_per_range` の最適値を見極める
デフォルトでは128ページですが、テーブルの行密度や、検索クエリの頻度に応じてここをチューニングする必要があります。範囲を大きくすればインデックスはさらに小さくなりますが、偽陽性（範囲内にはないのに、あると判定されてしまう）が増え、フィルタリング負荷が上がります。
- `autosummarize` の重要性
`VACUUM`や`INSERT`でデータが追加された時、インデックスの範囲が自動で更新されるように設定（`autosummarize = on`）しておかないと、新しいデータが検索から漏れるという悲劇が起こります。デフォルトで有効ですが、インポート処理が多いバッチジョブの直後などは、手動で `brin_summarize_new_values()` を叩く習慣をつけておくと安心です。
- 「更新」には極めて弱い
`UPDATE` が頻発するテーブルでBRINを使うのは避けましょう。ページ内のデータが書き換わると、その範囲の「最小・最大」が更新され、頻繁にインデックスの再構築（サマライズ）が必要になります。これは書き込み性能に直結します。
結論：どこで使うべきか
僕がBRINを推奨するのは、以下のようなケースです。
1. ログ、時系列データ、イベントデータ：`created_at` のような時系列カラムによる範囲検索がメインのテーブル。
2. 巨大な履歴テーブル：数億行を超え、B-treeだとインデックスだけで数十ギガバイトになってしまうような場合。
3. 読み取り専用、あるいは追記専用のデータ：物理的な並び順が維持されることが保証されているデータ。
BRINは魔法の杖ではありません。しかし、PostgreSQLの内部構造を理解し、データの特性とインデックスの仕組みをマッチングさせることができれば、これほどコストパフォーマンスの高い武器は他にありません。
「巨大データだから仕方ない」と諦める前に、まずは物理的な並び順を見直してみてください。PostgreSQLは、僕たちが適切にヒントを与えれば、驚くほどのパフォーマンスを見せてくれるはずです。
それでは、また次回の深掘りでお会いしましょう。
コメント