こんにちは！データベースの世界に飛び込んでから、もう長いことPostgreSQLと付き合ってきました。今日は、データベースの「インデックス（索引）」のちょっとマニアックだけど頼れる相棒、「ハッシュインデックス」についてお話ししようと思います。
「インデックスって何だっけ？」という方も大丈夫。まずは身近な例えから入っていきましょう。
—
本の「索引」と「メモ帳」の違い
図書館に行くと、本の後ろに「索引（インデックス）」がありますよね。「あいうえお順」に言葉が並んでいて、調べたい単語が何ページにあるかすぐにわかる。あれがデータベースで言うところのB-treeインデックスです。範囲検索（「AからZまで探す」みたいな）が得意で、普段一番よく使う優等生ですね。
一方で、ハッシュインデックスを例えるなら……そうですね、「冷蔵庫のドアに貼ったメモ」でしょうか。
「牛乳の残量」「卵の数」といった特定の項目だけをパッと確認したいとき、わざわざ「あいうえお順」に整理されたリストを見る必要はありませんよね。「牛乳」と書かれたメモを見れば、その答え（在庫状況）がすぐにわかる。
ハッシュインデックスは、まさにこれ。「これとこれが一致するか（＝等価比較）」を知りたいときだけ、ものすごい速さで答えを教えてくれる、特定の目的特化型のツールなんです。
—
ハッシュインデックスを使うメリットって？
「じゃあ、全部ハッシュインデックスにすればいいんじゃない？」と思うかもしれませんが、世の中そんなに甘くありません（笑）。
ハッシュインデックスの一番の魅力は、「コンパクトさ」です。
B-treeインデックスは、データの並び順を保つために、どうしてもインデックス自体のサイズが大きくなりがちです。でも、ハッシュインデックスは「値が一致するかどうか」さえ分かればいいので、B-treeよりもスリムに作れることが多いんです。
データ量が多いシステムで、「とにかく特定のIDだけを爆速で検索したい！」という時には、このスリムさが武器になります。
—
ちょっと待って！気をつけたい「落とし穴」
ここまで聞くといいことずくめに聞こえますが、データベースエンジニアとして、どうしても伝えておきたい「注意点」が2つあります。
1. 範囲検索ができない
「10歳から20歳までのユーザーを探したい」といった検索は、ハッシュインデックスではお手上げです。「一致する？」という質問には答えられても、「大きい？小さい？」という質問には答えられないんです。これがハッシュインデックスの最大の弱点ですね。
2. 「ログ」の交通渋滞（WALの話）
ここが一番のポイントです。PostgreSQLはデータの安全性を守るために、操作のたびに「WAL（書き込み先行ログ）」というメモを残します。
昔のハッシュインデックスはこのWALへの書き込みが非常に多く、レプリケーション（バックアップサーバーへのデータ同期）の時に、まるで渋滞のような負荷をかけてしまうことがありました。
最近のPostgreSQL（バージョン10以降）ではかなり改善されて、実用レベルで使いやすくなりましたが、それでも「インデックスを貼る＝書き込みが少し重くなる」という基本原則は変わりません。
—
まとめ：どう使い分ける？
最後に、僕が現場で心がけている「使い分けのルール」を置いておきますね。
- まずは「B-tree」を疑う： 迷ったらB-treeです。これだけで9割のケースは解決します。
- どうしてもサイズを削りたい時だけ「ハッシュ」を検討する： 巨大なテーブルで、特定のカラムを完全一致検索しかしないなら、ハッシュインデックスという選択肢が輝きます。
データベースの設計は、パズルのようなものです。「これが最強！」という万能ツールはなくて、状況に合わせて適材適所で選んでいくのが本当に面白いところなんですよ。
皆さんのプロジェクトでも、もしインデックスのサイズや検索速度で悩むことがあれば、「そういえばハッシュインデックスってのがあったな」と思い出してみてくださいね。
それでは、また次回の記事でお会いしましょう！Happy Coding!
コメント