やあ。今日もデータベースと格闘してるかい？
PostgreSQLを触っていると、必ずと言っていいほど「B-treeじゃどうにもならない壁」にぶつかる瞬間が来るよね。特に最近のアプリケーションだと、JSONBを使ってスキーマレスにデータを放り込んだり、タグ付け機能で配列を使ったりすることが増えてるはずだ。
そんな時、強力な武器になるのが GIN (Generalized Inverted Index) だ。名前はちょっと仰々しいけれど、考え方はシンプル。今日は、GINインデックスがなぜ最強の武器になるのか、現場の視点で噛み砕いて解説するよ。
—
GINインデックスって結局なんなの？
一言で言うと、「辞書の索引」だ。
B-treeインデックスは、値そのものの「大小関係」を並べるのに適している。でも、JSONBの中身や配列のように、「一つのカラムの中に複数の要素が詰まっているもの」を検索しようとすると、B-treeだとお手上げなんだ。
GINは、データの中に含まれる個々の要素をすべて分解して、「どの行にどの要素が含まれているか」というリストを作る。だから、「このタグが付いている行はどれ？」とか「このキーを持っているJSONBはどれ？」といったクエリを爆速にできるわけだ。
具体的な使用シーンを見てみよう
一番よく使うのは、やっぱり JSONBの検索 だね。例えば、ユーザーの属性データをJSONBで持っている場合を考えてみよう。
— ユーザーテーブルのプロフィールカラムにJSONBでデータを入れる
CREATE TABLE users (
id serial PRIMARY KEY,
profile jsonb
);
— こんなデータが入っているとする
— {“tags”: [“engineer”, “postgres”, “remote”], “status”: “active”}
「タグに `postgres` を含んでいるユーザーを全員出したい！」というとき、普通にクエリを投げると全件スキャン（フルスキャン）が走って、データ量が増えると悲惨なことになる。
そこで登場するのがGINだ。
CREATE INDEX idx_users_profile_tags ON users USING GIN (profile);
これだけで、`@>` 演算子（包含演算子）を使った検索が一気に高速化する。
SELECT FROM users
WHERE profile @> ‘{“tags”: [“postgres”]}’;
これ、実務で知っていると知らないとでは、パフォーマンスに天と地ほどの差が出るよ。
—
現場で気をつけるべき「2つの落とし穴」
「じゃあ、とりあえず全部GINを貼っておけばいいじゃん！」と思うかもしれないけれど、そこは落ち着こう。GINには守るべきルールがあるんだ。
1. 更新コストは「重い」と覚悟する
B-treeと違って、GINはデータを追加・更新するたびに、「分解した要素」のリストを更新しなきゃいけない。つまり、インデックスの更新負荷がかなり高いんだ。
読み込みが多いテーブルには最適だけど、秒間何千回も書き込みが発生するようなテーブルに無闇に貼ると、データベースの悲鳴が聞こえてくることになるよ。
2. 「fastupdate」の罠
デフォルトでは `fastupdate` という機能が有効になっていて、インデックスの更新を溜め込んでからまとめて処理するようになっている。これは書き込み性能には優しいんだけど、稀に読み込み時に一時的な遅延を生むことがあるんだ。運用していて「検索が急に遅くなる瞬間があるな？」と感じたら、このパラメータの調整を検討してみてほしい。
—
最後に：まずは試してみること
GINインデックスは、使いこなせば「PostgreSQLってこんなに速いの？」と驚かせてくれる魔法のような機能だ。特に、全文検索（`tsvector`）や、複雑な構造を持つJSONBを扱うアプリケーションでは、これがないと始まらないと言っても過言じゃない。
まずは、ステージング環境や手元の開発DBで、`EXPLAIN ANALYZE` を使ってインデックスがない時とある時の実行計画を見比べてみてくれ。あの「Seq Scan」が「Bitmap Index Scan」に変わる瞬間、エンジニアとしてちょっとした快感を覚えるはずだよ。
何か詰まったら、またいつでも聞きに来て。現場からは以上！
コメント