こんにちは！データベースエンジニアの日常へようこそ。
今日は、PostgreSQLのパフォーマンス改善において避けては通れない「ビットマップヒープスキャン（Bitmap Heap Scan）」という、ちょっと強そうな名前の仕組みについてお話しします。
名前からして難しそうですよね。「ビットマップ？ヒープ？スキャン？何語？」ってなる気持ち、すごくよくわかります。でも大丈夫。実はこれ、私たちの日常生活にある「ある行動」に例えると、ものすごくスッキリ理解できるんです。
—
図書館で「探したい本」をどう見つける？
想像してみてください。あなたは今、とてつもなく巨大な図書館にいます。ここには何百万冊もの本（データ）が並んでいます。
あなたは「プログラミングの本」かつ「2023年以降に出版されたもの」という条件で本を探したいとします。
方法1：インデックススキャン（付箋をたどる）
一番シンプルなのは、インデックス（索引）を使うこと。「プログラミング」の棚に行って、1冊ずつ確認して、条件に合うものを拾い上げる。これは早くて確実です。でも、もし条件が複雑で、何度も往復が必要だったらどうでしょう？ あっちの棚、こっちの棚と走り回って、足が棒になってしまいますよね。
方法2：ビットマップヒープスキャンの登場
ここで「ビットマップヒープスキャン」の出番です。これは、「事前に必要な本の場所をメモしてから、最後にまとめて取りに行く」という賢いやり方なんです。
1. 「プログラミングの本の場所」のリストを作る。
2. 「2023年以降の出版物の場所」のリストを作る。
3. この2つのリストを突き合わせて、「両方の条件を満たす場所」の地図（これがビットマップです！）を紙に描く。
4. その地図を持って、図書館の棚を最短距離で効率よく巡回する。
どうでしょう？ 一つひとつ確認して右往左往するより、地図を作ってから一気に回収したほうが、結果的に早く終わりますよね。これが、PostgreSQLが裏側でやっていることなんです。
—
影の主役「work_mem」の存在
さて、ここで重要になるのが「work_mem（ワークメモリ）」という設定項目です。
さっきの例で言うと、work_memは「地図を描くためのメモ用紙の大きさ」だと思ってください。
- メモ用紙（work_mem）が十分にある場合：
余裕を持って詳細な地図が描けます。「この棚の何番目から何番目まで！」と正確に把握できるので、効率よく本を回収できます。
- メモ用紙（work_mem）が小さすぎる場合：
書ききれませんよね。するとPostgreSQLは「あ、これ以上細かく書けないから、大まかな場所だけ覚えておこう」と、地図を省略してしまいます。すると、本来関係ない本までチェックすることになり、結局無駄足が増えてパフォーマンスが落ちてしまうんです。
—
初心者の方が知っておくべき「落とし穴」
「じゃあ、work_memをめちゃくちゃ大きくすれば最強じゃない？」と思いますよね。ところが、そうもいかないのがデータベースの面白い（そして難しい）ところ。
work_memは「同時につながっているユーザー一人ひとり」に割り当てられるメモリです。これを欲張って大きくしすぎると、図書館の入り口で大行列ができて、逆にシステム全体がパンクしてしまいます。「過ぎたるは及ばざるが如し」ですね。
まとめ：今日覚えて帰ってほしいこと
1. ビットマップヒープスキャンは、バラバラな条件を一度「地図」にしてから、効率よくデータを取りに行く賢い手法。
2. work_memは、その地図を描くための作業机の広さ。
3. データベースの動きが遅いな？と感じたら、「もしかして作業机（work_mem）が狭くて、効率的な地図が描けていないのかも？」と疑ってみるのが、エンジニアへの第一歩です。
データベースのチューニングは、料理の味付けに少し似ています。塩（メモリ）を足しすぎても足りなくてもダメ。自分のシステムの「ちょうどいい」を見つけるのが、一番の醍醐味なんです。
ぜひ、皆さんの環境でも「このクエリ、どんな動きをしてるんだろう？」とEXPLAINコマンドで覗いてみてくださいね。きっと新しい発見があるはずですよ！
それでは、また次回の記事でお会いしましょう！
コメント