PostgreSQLのハッシュインデックス：忘れ去られた「特化型」の深淵を覗く
PostgreSQLの世界にどっぷり浸かっていると、どうしてもB-treeインデックスの万能感に頼り切りになってしまいますよね。レンジスキャンもできるし、ソートも効く。まさに「困ったらB-tree」という教条主義が蔓延するのも無理はありません。
しかし、等価比較（`=`）だけで戦うと決めた時、ハッシュインデックスという「一芸に秀でた怪物」が牙を剥くことを忘れてはなりません。今日は、そんなハッシュインデックスの内部構造と、現場で遭遇するトラブルの解剖学について話をしましょう。
—
1. 内部構造：バケットとメタページの静かなる戦い
ハッシュインデックスは、B-treeのような階層構造を持ちません。その本質は「バケット」への直接的なマッピングです。
PostgreSQLのハッシュインデックスは、インデックス作成時に指定されたデータに対しハッシュ関数を適用し、その結果をもとにバケットを決定します。内部的には以下の要素で構成されています。
- メタページ（Meta Page）: インデックスの「司令塔」です。現在使用しているバケットの数や、次に拡張すべきタイミングなどの統計情報を保持しています。
- バケットページ（Bucket Pages）: 実際のハッシュ値が格納されるメインの領域。
- オーバーフローページ（Overflow Pages）: いわゆる「ハッシュ衝突」が発生した際に活躍する救済策。バケットが溢れると、連結リストのようにチェーンが伸びていきます。
かつてのPostgreSQL（v10以前）では、ハッシュインデックスはWALに書き込まれず、クラッシュリカバリのたびにインデックスが壊れるという悪名高い存在でした。しかし、今の私たちは幸運です。現在のハッシュインデックスはWALをサポートし、高い信頼性を手に入れました。
—
2. なぜB-treeではなくハッシュを選ぶのか？
「B-treeでも等価比較は速いのでは？」という疑問は当然です。しかし、大規模データセットにおけるルックアップの「深さ」を考えてみてください。
B-treeは木構造である以上、ツリーの深さ分だけページを読み込む必要があります。一方、ハッシュインデックスは（衝突さえ少なければ）理論上のアクセス回数は極めて一定です。特に、非常に長い文字列や、インデックスキーのサイズが大きい場合、B-treeのノードはすぐに肥大化し、ページの分割（Split）コストが無視できなくなります。
ハッシュインデックスは、「ソートは不要、ただ一点をミリ秒以下で引き当てたい」という究極の単一目的において、B-treeよりもコンパクトかつ高速に動作するポテンシャルを秘めています。
—
3. パフォーマンストラブルシューティング：現場で見極めるべきサイン
ハッシュインデックスを運用する際、以下の兆候が見えたら要注意です。
1. 検索速度の漸進的な低下
もし、以前よりもルックアップが遅くなっていると感じたら、まずは `pg_stats` を疑うよりも先に、インデックスの「フィルファクター（Fill Factor）」とバケットの溢れ具合を確認しましょう。オーバーフローページへのチェーンが長くなると、メモリ上のページアクセスが連鎖し、性能はガタ落ちします。
2. 「バケットの偏り」問題
ハッシュ関数が優秀であっても、データ自体に偏りがあれば衝突は避けられません。特定の値にリクエストが集中するようなワークロードの場合、ハッシュインデックスは「単なるリストの線形探索」になり果てます。
3. トラブル対応の処方箋
もし性能に違和感を覚えたら、迷わず `REINDEX` です。
PostgreSQL 10以降のハッシュインデックスは、動的にバケット数を拡張できるようになりましたが、一度肥大化して断片化したインデックスは、整理してやるのがエンジニアの流儀です。
—
結論：使いどころを選ぶ「職人道具」
ハッシュインデックスは、決して万能薬ではありません。B-treeが「誰にでも使いやすい万能ナイフ」なら、ハッシュインデックスは「特定の素材を切り出すためだけに研ぎ澄まされた日本刀」です。
- `ORDER BY` や `LIMIT` が絡むクエリには使えない。
- マルチカラムインデックスが作れない（現状の制約）。
これらの制約を理解した上で、「この巨大なテーブルのUUID検索だけは、何があっても最速で返したい」というような、クリティカルな要件に出会った時こそ、このインデックスを思い出してください。
データベースの奥底で、ハッシュ計算がコンマ数ミリ秒を削り出している……。そんなアーキテクチャの美しさを感じながら、今日もクエリを最適化していきましょう。
それでは、また次の深い場所でお会いしましょう。
コメント