ハッシュインデックスを巡る「誤解」と「真実」：PostgreSQLにおける最適解を見極める
PostgreSQLを長く触っていると、誰もが一度は「B-tree以外のインデックスに救いを求める瞬間」が訪れます。特定のカラムに対する等価比較（`=`）が主体のクエリで、インデックスサイズを極限まで削りたい。そんなとき、多くのエンジニアがちらりと横目で見るのが「ハッシュインデックス」でしょう。
しかし、PostgreSQLにおけるハッシュインデックスは、かつて「本番投入厳禁」という不名誉なレッテルを貼られていた時期がありました。PostgreSQL 10で劇的に改善され、WALログへの書き込みもサポートされた現在、私たちはどう向き合うべきなのか。今日は、その内部構造と、現場で踏み抜く地雷について深掘りしてみます。
—
内部構造：バケットとオーバーフローページの静かな戦い
ハッシュインデックスのアーキテクチャは、非常にシンプルです。キーのハッシュ値を計算し、それを基にバケットを決定する。B-treeのような木構造を辿るオーバーヘッドがないため、理論上は「キーが一致する場所へ最短距離で直行する」ことが可能です。
PostgreSQLのハッシュインデックスは、以下の構成で成り立っています。
- メタページ: インデックス全体の管理情報。
- バケットページ: ハッシュ値に対応する主ページ。
- オーバーフローページ: バケットが溢れたときに使われる連結リスト。
ここで注意すべきは、「衝突（Collision）」のハンドリングです。ハッシュ値が同一になった場合、インデックスはオーバーフローページへと連鎖します。もし対象のデータセットでハッシュの衝突が頻発すれば、インデックスのルックアップは単なる「連結リストの線形探索」に成り下がります。
なぜB-treeではなくハッシュを選ぶのか？
「B-treeで十分では？」という問いは、もっともです。しかし、巨大な文字列カラムをインデックス化する場合、B-treeはノードの分割（Page Split）を繰り返し、ツリー構造を維持するために多大なコストを支払います。
対してハッシュインデックスは、キーの長さに関わらずハッシュ値を計算して格納するため、インデックスサイズを劇的に小さくできるケースがあるのです。メモリに乗るフットプリントが小さくなれば、キャッシュ効率は上がり、結果としてI/Oのレイテンシが劇的に改善します。これが、適切に設計されたハッシュインデックスが持つ破壊力です。
—
避けては通れない「レプリケーション」の壁
ここからは、少し技術的な戒めを。PostgreSQL 10以降、ハッシュインデックスはWALログに書き込まれるようになったため、レプリケーション環境でも安全に使えるようになりました。しかし、パフォーマンスの観点では「まだ油断は禁物」です。
1. WAL生成コスト: ハッシュインデックスは更新時に、B-treeよりも書き込みの増幅（Write Amplification）が大きくなる傾向があります。高頻度で更新されるカラムに適用すると、WALの肥大化がレプリケーションラグの直接的な原因になります。
2. インデックスの再構築: ハッシュインデックスはB-treeのように「バランスを保つ」という概念がありません。データが偏った場合、バケットの再配置（Split）が行われますが、この処理中のロック競合は無視できないレベルに達することがあります。
—
パフォーマンストラブルの勘所
もし本番環境でハッシュインデックスのパフォーマンスが想定通りに出ない場合、以下のポイントを確認してください。
- ハッシュ関数の偏り: 特定のデータパターンに対してハッシュ値が偏っていないか。
- バケット数（Fillfactor）: デフォルト値のままにしていませんか？ データ量が予測できるのであれば、初期のバケット数を調整することで、オーバーフローを未然に防ぐことができます。
- クエリプランナーの裏切り: 「等価比較以外も使う可能性がある」なら、迷わずB-treeを選んでください。ハッシュインデックスは、範囲検索（`>` や `<`）やソート処理には一切貢献しません。クエリプランナーが「インデックススキャン不可」と判断した瞬間、フルスキャンが回り、夜中にアラートが鳴ることになります。
結論：ハッシュインデックスは「特効薬」である
ハッシュインデックスは、万能選手ではありません。特定のユースケース――例えば、ログのシグネチャ、巨大なユニークIDの照合、あるいは読み取り専用の巨大なルックアップテーブル――においてのみ、その輝きを放ちます。
もしあなたが「インデックスサイズが大きすぎてキャッシュ効率が悪い」という壁にぶつかっているのなら、一度ハッシュインデックスを検討する価値はあります。ただし、導入の際は必ずEXPLAIN ANALYZEで実際のコストを計測し、WAL書き込み量とのバランスを考慮すること。
エンジニアリングとは、銀の弾丸を探すことではなく、限られた制約の中で最適なトレードオフを選択し続けること。ハッシュインデックスはその選択肢の一つとして、あなたのツールボックスにそっと忍ばせておくべき強力な兵器なのです。
さて、次はどのインデックス構造を解剖しましょうか。また次回お会いしましょう。
コメント