こんにちは！データベースの世界へようこそ。
普段、何気なく使っているデータベースですが、データを検索するスピードを速くするための「インデックス（索引）」という仕組み、少し気になりませんか？
今日は、PostgreSQLに備わっている「Hash（ハッシュ）インデックス」という、ちょっと尖った性格の機能についてお話ししようと思います。
—
辞書（B-tree）と、ロッカーの鍵（Hash）
まず、データベースのインデックスで最も有名な「B-tree（ビーツリー）インデックス」をイメージしてみてください。これは厚い辞書のようなものです。言葉が順番に並んでいるから、「あいうえお順」で探せば目的のページにたどり着けますよね。これはこれで万能選手です。
一方、今回紹介する「Hashインデックス」は、例えるなら「駅のコインロッカー」です。
コインロッカーに荷物を預けるとき、あなたは「このロッカー！」と決めた番号の場所に直接向かいますよね。中身が「あいうえお順」に並んでいるかどうかは関係ありません。「この鍵なら、このロッカーだ！」と一発で決まる。これがHashインデックスの仕組みなんです。
どんなときに使うのが正解？
Hashインデックスは、「＝（イコール）」で検索するときに爆速になります。「このIDのデータを探して！」「このメールアドレスの人を調べて！」といった、完全一致の検索ですね。
逆に、「この数値より大きいものを探して（範囲検索）」といった用途には全く向いていません。コインロッカーは「3番よりも大きい番号のロッカー」を探すのには不向きですよね。それと同じなんです。
—
Hashインデックスの「隠れたメリット」
「じゃあ、B-treeで十分じゃない？」と思うかもしれません。でも、Hashインデックスには意外な実力があるんです。
- メモリとサイズの効率性
B-treeインデックスは、データの順序を保つために構造が少し複雑になりがちです。その点、Hashインデックスは必要な情報だけに絞り込めるので、インデックス自体をコンパクトに保ちやすいという利点があります。
- 書き込みのストレスを減らす
データベースに新しいデータを追加するとき、B-treeだと「どこに挿入すべきか」を考えながら並び替えをする必要があります。でもHashなら、「計算して、そこにドン！」と置くだけ。このシンプルさが、書き込み処理の負担を軽くしてくれるんです。
—
昔は「お騒がせ」、今は「頼れる相棒」
実は、昔のPostgreSQLでHashインデックスを使うのは、少し勇気がいることでした。というのも、システムが突然ダウンしたときにデータが壊れてしまうリスクが少し高かったんです。
でも、PostgreSQL 10というバージョンから状況が一変しました。「WAL（Write-Ahead Logging）」という、データベースの「お買い物メモ」のような仕組みにしっかり対応したことで、万が一の故障時でもデータを安全に復旧できるようになったんです。
今では、安心して現場で使える「頼れる相棒」に進化しているんですよ。
—
まとめ：使い分けがプロへの第一歩
データベースのチューニングにおいて、「これさえ使えば万事解決！」という魔法の杖は存在しません。
- B-tree： 範囲検索もできるし、並び替えも得意な「優等生」。まずはこれから使いましょう。
- Hash： 「＝（イコール）」検索だけの用途なら、ピンポイントで輝く「職人肌」。
もしあなたが「特定のIDを頻繁に検索するけれど、範囲検索は全くしないんだよね」というテーブルを扱っているなら、Hashインデックスを検討してみる価値は十分にあります。
データベースの世界は、こうやって「状況に合わせて適材適所を選ぶ」のが本当に面白いところです。ぜひ、皆さんの環境でも試してみてくださいね。
それでは、また次回の記事でお会いしましょう！
コメント