こんにちは！データベースの世界にどっぷり浸かっているエンジニアです。
今日は、PostgreSQLの「裏側」でひっそりと、でもすごく重要な仕事をしている「ビットマップヒープスキャン」についてお話ししようと思います。
名前を聞くと「うわ、難しそう…」って思いますよね。でも、実はこれ、私たちの日常生活にある「ある行動」と全く同じなんです。
—
巨大な図書室で「お目当ての本」を探すとき
想像してみてください。あなたは今、数万冊の本が並ぶ巨大な図書室にいます。
「特定のキーワードが書かれた本を全部持ってきて！」と頼まれたとしましょう。
普通の探し方（インデックススキャン）
インデックス（索引）を使って、本棚を行ったり来たりするやり方です。
「あ、1冊目はA棚ね。よし、A棚へ走る！……次はB棚か、B棚へ走る！」
これ、本が数冊ならいいんですが、もし「A棚の3冊、B棚の5冊、C棚の10冊…」とバラバラに散らばっていたらどうでしょう？ 何度も同じ場所を行ったり来たりして、めちゃくちゃ疲れますよね。これだと非効率なんです。
ビットマップヒープスキャンの賢いやり方
そこで登場するのが、今回紹介する「ビットマップヒープスキャン」です。このやり方は、もっと頭を使います。
1. まずはメモ帳を用意する： まずは索引を見て、必要な本がどこにあるかを全部確認します。
2. 「地図」を塗る： どこにあるか分かったら、館内図の該当する場所に「ここ！ここ！ここ！」とチェック（ビットを立てる）を入れていきます。
3. 効率的なルートで回収する： チェックが終わったら、館内図を見ながら「なるほど、今回はこの列とこの列を回れば、全部回収できるな」と、最短ルートを考えます。
4. 一気に回収： 本棚を何度も往復することなく、効率よく本を回収して戻ってくる。
これが、「ビットマップヒープスキャン」の正体です！
—
なぜこれが「すごい」のか？
専門的な話を少しだけ噛み砕くと、こういうことです。
- 無駄な往復を減らす： ストレージ（ハードディスクやSSD）は、実は「あっちこっち」読みに行くのが一番苦手なんです。ビットマップヒープスキャンは、読み込む場所を事前に整理してから取りに行くので、ストレージに優しい動きをしてくれます。
- メモリで賢く整理： 「ビットマップ」というのは、要は「どのページにデータがあるか」を0と1で記録した小さな地図です。これをメモリ上でパパッと処理するので、すごく速いんです。
まとめ：PostgreSQLは「段取り」が上手
データベースって、ただデータを保存しているだけじゃなくて、こうやって「どうすれば一番効率よく、速く、疲れないでデータを持ってこれるか」を常に考えているんです。
「ビットマップヒープスキャン」は、「一度にまとめて処理したほうが、結果的に速いよね」という、私たちの仕事術にも通じる知恵が詰まっているんですよ。
もし皆さんがPostgreSQLを使っていて、「あ、今このクエリはビットマップヒープスキャンしてるな」と気づいたら、それはPostgreSQLが「最短ルートを計算して頑張ってるんだな」と優しく見守ってあげてくださいね。
また次回の記事でも、データベースの面白い仕組みを紐解いていきましょう！質問や感想があれば、ぜひ気軽に教えてくださいね。それでは！
コメント