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

皆さん、こんにちは！データベースの世界へようこそ。

今日は、PostgreSQLを使っていると時折耳にする、ちょっと不思議な存在「BRINインデックス」についてお話ししようと思います。「インデックス」と聞くと、多くの人が「検索を速くするための魔法の杖」をイメージしますよね。

でも、数億件、数十億件という「巨大なテーブル」を扱うとき、普通のインデックスを作ると、今度はそのインデックス自体が肥大化しすぎて、かえってデータベースの足を引っ張ってしまう……なんて悲劇がよく起こるんです。

そんなとき、救世主として現れるのが「BRIN（Block Range Index）」です。今日は、この子の賢い仕組みを、日常の例えで紐解いていきましょう。

—

想像してみてください。あなたは巨大な図書館の司書さんです。
本が100万冊あるとして、特定の1冊を探すとき、どうしますか？

通常、私たちは「索引（インデックス）」を作りますよね。これがあれば、本のタイトルや著者名から、即座に「何番の棚のどこにあるか」がわかります。でも、本が10億冊あったらどうでしょう？索引を作るためのカードだけで、図書館の床が埋め尽くされてしまいますよね。

ここで、BRINはこう考えます。
「いちいち1冊ずつ場所を特定しなくても、『このエリアには、AからCの著者しかいない』ということさえ分かれば、それで十分じゃない？」

BRINは、データが「物理的に並んでいる順番」を最大限に活用します。

普通のインデックスが「1冊ずつの住所録」だとすれば、BRINは「本棚のエリアごとの範囲メモ」です。

こんな風に、データの塊（ブロック）ごとに「ここには最小でこれ、最大でこれくらいの値があるよ」という情報をメモしておくんです。

もしあなたが「1月7日のデータを探したい」と思ったら、BRINはこう答えてくれます。
「1月7日？それなら101番以降の本棚のどこかにあるはずだよ！他のエリアは無視していいよ！」

これだけです。1冊ずつの正確な場所は教えませんが、「探さなくていい場所」を豪快に切り捨ててくれるので、結果として目的のデータにたどり着くまでの時間が劇的に短縮されるわけです。

このBRIN、実はとても「人を選ぶ」インデックスです。どんな時でも万能なわけではありません。

BRINが最高のパフォーマンスを発揮するのは、「データが時系列順に並んでいるとき」です。

例えば、ログデータやセンサーのデータ。これらは常に新しいものが末尾に追加されていきますよね。この「順番に並んでいる」という性質があるからこそ、BRINの「ざっくり地図」が正確に機能します。

逆に、バラバラのタイミングでデータが更新されたり、ランダムにデータが挿入されるテーブルでは、BRINの地図はすぐにボロボロになって役に立たなくなってしまいます。

BRINの魅力をまとめると、こんな感じです。

「とりあえず何でもインデックスを貼れば速くなる」というのは、データベース設計の入り口でよくある落とし穴です。でも、BRINのような「賢い妥協」を知っておくと、巨大なデータを扱うときの景色が少し変わって見えてきませんか？

皆さんのデータベースに、もし「巨大で、かつ順番に並んでいるテーブル」があったら、ぜひ一度BRINのことを思い出して試してみてください。

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