PostgreSQLのHashインデックス：その「誤解」と「真の使いどころ」を解き明かす
PostgreSQLを長年触っていると、インデックスの選択肢はほとんど「B-tree」で埋め尽くされてしまうのが現実ですよね。ほとんどのケースでB-treeは最強です。しかし、特定の要件において、Hashインデックスは驚くべきパフォーマンスを見せることがあります。
今回は、忘れられがちなHashインデックスの内部構造と、なぜ彼らが「等価比較」という一点に命を懸けているのか、その深淵を覗いてみましょう。
なぜB-treeではないのか：メモリと構造のトレードオフ
まず、前提を共有させてください。B-treeは非常に優秀な「万能選手」です。ソート順を保持し、範囲検索（`<`, `>`, `BETWEEN`）が可能なため、SQLのクエリの9割はこれで解決します。
一方、Hashインデックスは文字通り「ハッシュテーブル」です。インデックスキーをハッシュ関数で計算し、対応するバケットにマッピングします。
ここで注目すべきは、B-treeが持つ「木構造の深さ」というオーバーヘッドがないという点です。B-treeは検索時にノードを辿る（ページI/Oが発生する）必要がありますが、Hashインデックスはハッシュ値さえ分かれば、計算上は最小限のアクセスでターゲットに到達できます。
特に、巨大なテーブルで、インデックスのサイズがメモリ上の共有バッファ（`shared_buffers`）に乗り切らないようなケースにおいて、HashインデックスはB-treeよりもページアクセスの回数を劇的に減らせるポテンシャルを秘めています。
内部アーキテクチャ：PostgreSQL 10以降の「進化」
以前（PostgreSQL 9.6以前）のHashインデックスは、実はクラッシュセーフではなく、レプリケーションとも相性が最悪でした。しかし、現代のPostgreSQLにおけるHashインデックスは、WAL（Write Ahead Log）にしっかり書き込まれ、堅牢な構造になっています。
メタページとバケットの構造
Hashインデックスの内部は、大きく分けて「メタページ」「バケットページ」「オーバーフローページ」で構成されています。
- メタページ: インデックス全体の制御情報を持ちます。
- バケットページ: ハッシュ値から導き出された一次格納場所です。
- オーバーフローページ: バケットが溢れた（ハッシュコリジョンが発生した）際に使われる連鎖領域です。
ここでのポイントは、「ハッシュコリジョンをどう扱うか」です。PostgreSQLのHashインデックスは、ハッシュ値が衝突した場合、単に同じバケットに繋いでいくだけではなく、効率的にスキャンできるように設計されています。とはいえ、あまりにコリジョンが多いと、結局バケット内を線形探索することになり、パフォーマンスは急落します。
チューニングの勘所：ここだけは押さえておこう
Hashインデックスを実戦投入する際、私がいつもチェックするのは以下の点です。
1. 「等価比較」以外には絶対に手を出さない
これは鉄則です。`WHERE col = ‘value’` 以外のクエリ、つまり範囲検索や `ORDER BY` が必要なクエリに対してHashインデックスを使っても、PostgreSQLはインデックスを無視してシーケンシャルスキャンを選択するか、インデックスをフルスキャンしてしまい、最悪の結果を招きます。
2. データ型の選定とハッシュ関数
Hashインデックスの性能は、ハッシュ関数の品質に直結します。基本的には標準のハッシュ関数で十分ですが、独自データ型を扱う場合は注意が必要です。また、`UUID` や長い文字列の比較にはHashインデックスが有効ですが、逆に短い整数値であれば、B-treeの方がキャッシュ効率が良いことも多々あります。
3. モニタリング：`pg_stat_user_indexes` の視点
もし「Hashインデックスを使っているのに遅い」と感じたら、まずは `pg_stat_user_indexes` を確認してください。
- インデックスの肥大化はないか？
- `idx_scan` が想定以上に増えていないか？
- もしかして、オーバーフローページを頻繁に読みに行っていないか？
もしハッシュ衝突がボトルネックになっているなら、それはインデックスの再構築（`REINDEX`）のサインかもしれません。
結論：いつ、Hashインデックスを選ぶべきか
私の現場での経験則ですが、Hashインデックスが光るのは、「巨大なテーブルに対する単一キーのルックアップ（等価検索）が極めて頻繁に発生し、かつ、そのインデックスサイズが物理メモリの限界に近いとき」です。
B-treeのインデックスサイズが肥大化し、インデックスのスキャンだけでI/Oが枯渇するような状況に陥ったとき、Hashインデックスは「隠し玉」として期待に応えてくれます。
「とりあえずB-tree」の思考停止を脱し、データとクエリの性質を見極めてHashインデックスを使いこなす。それこそが、PostgreSQLを極めようとするエンジニアの醍醐味ではないでしょうか。
皆さんのデータベースに、Hashインデックスが刺さる余地はありますか？ぜひ、検証環境で試してみてください。驚くような数字が見られるかもしれませんよ。
コメント