巨大なログデータに「B-tree」を貼るのはやめよう。BRINインデックスで賢く省エネ運用する話
やあ。最近、ログテーブルやセンサーデータの肥大化に頭を抱えているエンジニアから相談を受けることが多いんだ。
数億行のテーブルを前にして、「とりあえずインデックスを貼らなきゃ」と脊髄反射でB-treeインデックスを作成して、ディスク容量が爆発して泣きを見た……なんて経験はないかな？
もし君が扱っているのが「時系列データ」なら、B-treeは一旦忘れていい。今回は、PostgreSQLの隠れた（いや、もっと評価されるべき）名選手、BRIN（Block Range Index）について、実務的な視点で深掘りしてみよう。
—
1. なぜ「巨大なデータ」にB-treeは向かないのか？
B-treeは万能だよ。ランダムアクセスには最適だし、どんなデータ分布でも安定した性能を出す。でも、データ量がテラバイト級になってくると、インデックスサイズ自体が数ギガバイト、時には数十ギガバイトに膨れ上がる。
インデックスが巨大になると、メモリ（shared_buffers）に乗り切らなくなって、結局ディスクI/Oがボトルネックになる。それに、インデックスの更新コスト（メンテナンス）もバカにならない。
ここで登場するのがBRINだ。
2. BRINはどうやって「軽さ」を実現しているのか
BRINの仕組みはシンプルだ。「テーブルをブロック（ページ）の範囲で区切り、その範囲内の最小値と最大値だけを記録する」というもの。
例えば、128ブロックを1つの範囲（Range）とすると、その範囲の中に「どんな値が入っているか」というメタデータだけを保持するんだ。B-treeが個々の行を指し示すのに対して、BRINは「このエリアにあるかもしれないよ」という大まかな情報を指し示す。
- 圧倒的な小ささ: B-treeと比べて、インデックスサイズが数十分の一、場合によっては数百分の一になる。
- 低いメンテナンスコスト: インデックスの更新が非常に軽い。
3. 「物理的な順序」が命という話
BRINを採用する上で、唯一にして最大の注意点がある。それは「データが物理的にソートされていること」だ。
時系列データなら、通常は `INSERT` される順に時間が流れるよね。これなら、テーブルの物理的な並び順とデータの値が相関しているから、BRINは爆速で機能する。
逆に、ランダムなIDを主キーにしているようなデータに対してBRINを貼っても、「全範囲にすべての値が存在する」という判定になり、ただのスキャンと変わらなくなってしまう。「データの値と物理的な格納順序が相関している」ときこそが、BRINの輝き時なんだ。
4. 実践：`pages_per_range` をどう設定するか
BRINを使うとき、最も悩むのが `pages_per_range`（1つの範囲に何ブロック含めるか）の設定だ。
CREATE INDEX idx_brin_created_at ON logs USING BRIN (created_at)
WITH (pages_per_range = 32);
- 値を小さくする（例: 4〜16）: 検索精度は上がるが、インデックスサイズが大きくなる。
- 値を大きくする（例: 64〜128）: インデックスは極小になるが、範囲が広すぎて「無駄なスキャン」が増える。
僕からのアドバイス:
デフォルトは128だけど、まずはデフォルトで試して、`EXPLAIN ANALYZE` を見てほしい。明らかに範囲が広すぎて読み込み量が多いなら 32 や 16 に絞る。逆に、インデックスサイズを極限まで削りたいなら 256 にしてもいい。
ここには「正解」がない。データの増加ペースとクエリの頻度を見ながら、本番環境のテストで調整する。この「泥臭いチューニング」こそが、DBエンジニアの醍醐味だよ。
5. まとめ：BRINは「適材適所」の極み
BRINは魔法の杖じゃない。万能なB-treeの代わりにはならないんだ。
- B-tree: 特定の行をピンポイントで引く。メモリに乗せたい。
- BRIN: 膨大な時系列データの「期間検索」を劇的に軽くする。ディスクを節約したい。
もし君が、「ログテーブルが大きすぎてVacuumの負荷も高いし、ディスクもカツカツだ」と悩んでいるなら、一度BRINの検討をおすすめするよ。
最後に一つだけ。BRINは「追記型」のデータには強いけど、頻繁に `UPDATE` が発生するテーブルには向かない。読み取り専用に近いログやアーカイブデータでこそ、その真価を発揮するんだ。
よし、今日はここまで。また何か詰まったら聞きに来てくれ。君のデータベースが、今日も健やかに動くことを祈っているよ。
コメント