【入門編】 BRINインデックス – PostgreSQL

巨大なデータと戦うエンジニアの救世主、「BRINインデックス」って何？

こんにちは！日々データベースと格闘しているエンジニアです。

皆さんは、何億行もあるような巨大なテーブルを扱うとき、検索の遅さに頭を抱えたことはありませんか？「インデックスを貼れば速くなるよ！」と言われてB-treeインデックス（一番よく使われるやつですね）を作ってみたものの、インデックス自体が肥大化しすぎて、かえってディスクを圧迫してしまった……なんて経験、一度はあるはずです。

そんなとき、PostgreSQLの隠れた「秘密兵器」として活躍するのが、今回紹介するBRIN（Block Range Index）という仕組みです。

今日は、専門用語を抜きにして、「どうしてBRINがすごいの？」という話を、身近な例えを交えてお話ししますね。

—

「図書館の本」で例えると、こんな感じ

皆さんは巨大な図書館を想像してみてください。本が何百万冊と並んでいる広大なフロアです。

普通のインデックス（B-treeなど）：

これは「すべての本のタイトルと位置を記した、超緻密な索引カード」です。一冊一冊の場所が完璧にわかるので、探し物は一瞬で見つかります。でも、本が増えれば増えるほど、その索引カード自体が本棚と同じくらいの巨大さになってしまい、管理が大変ですよね。

BRINインデックス：

これは「本棚の端っこに貼られた、ざっくりしたメモ」です。
「この棚には、あいうえお順で『あ』から『こ』までの本が入っているよ」という情報だけを書き込んでおくんです。

「あれ？それじゃあ正確な場所がわからないじゃないか！」と思いましたか？
その通り。でも、「とりあえず、このエリアには目的の本はないな」と判断して、その棚全体を読み飛ばすことはできますよね。

BRINは、この「ざっくりとした絞り込み」をすることで、膨大なデータの中から、関係ないエリアを猛スピードでスルーする仕組みなんです。

—

なぜそんなに「軽量」なの？

B-treeインデックスが「本一冊ごとの住所録」を作るのに対し、BRINは「ブロック（データの塊）」という大きなグループ単位で、「この範囲には最小でA、最大でBの値が入っているよ」というメモ帳を作るだけなんです。

だから、インデックスのサイズが驚くほど小さい。
何億行というデータがあっても、インデックスは数メガバイト程度で済んでしまうことも珍しくありません。これなら、サーバーのメモリやディスクを圧迫することなく、巨大なテーブルに導入できるんです。

どんな時に使うと幸せになれる？

BRINは魔法の杖ではありません。使うにはちょっとした「コツ」が必要です。

データが物理的に並んでいること：

これが一番大切です。例えば「時系列データ（ログやタイムスタンプ）」のように、データが追加された順に物理的に並んでいるテーブルには最強です。

巨大すぎて他のインデックスが載らないとき：

「インデックスが巨大すぎてメモリに乗らない！」という悲鳴を上げているとき、BRINに切り替えるだけで劇的に改善することがあります。

逆に、データがバラバラに混ざっているようなテーブルだと、どの範囲にも「最小から最大まで全部入っている」という状況になり、インデックスが役に立たなくなってしまいます。「本棚の中身がめちゃくちゃに混ざっている」状態だと、メモを見てもどこにあるか分からないのと一緒ですね。

—

まとめ：まずは試してみよう

PostgreSQLのすごいところは、こうしたニッチな機能も標準で備えているところです。もし、皆さんのプロジェクトで「テラバイト級のログデータ」を扱っていて、「検索が重いけどインデックスを貼る空き容量がない！」と悩んでいたら、ぜひBRINを試してみてください。

CREATE INDEX idx_my_table_brin ON my_table USING BRIN (created_at);

たったこれだけの記述で、サーバーの負担を劇的に減らせるかもしれません。

データベースのチューニングは、パズルを解くようで本当に楽しいですよね。また何か面白い機能を見つけたら、ここでシェアしますね！

それでは、また次回の記事でお会いしましょう！