GINインデックス、お前を使いこなすには「覚悟」が必要だ
やあ。最近、PostgreSQLのパフォーマンスチューニングで頭を抱えているメンバーが多いみたいだね。特にJSONBや配列型をガッツリ使い始めたあたりで、「検索が遅い」とか「更新が急に重くなった」なんて相談をよく受ける。
その犯人の多くは、GIN (Generalized Inverted Index) の特性を正しく理解せずに使っていることにあるんだ。今日は、この強力だけど少し気難しい「GIN」という武器を、どうすれば安全かつ最強に使いこなせるか、現場の視点でガッツリ解説していくよ。
—
GINは「逆引き辞書」だと思えばいい
まず、GINが何をしているのかイメージしよう。B-treeインデックスが「値の大小関係」を整理する辞書なら、GINは本の巻末にある「索引（キーワードリスト）」だ。
例えば、JSONBの中に `{“tags”: [“tech”, “postgres”, “performance”]}` なんてデータが入っているとする。GINはこれを見て、
- “tech” はID: 1のレコードにある
- “postgres” はID: 1のレコードにある
- “performance” はID: 1のレコードにある
という風に、「値からIDを逆引きできるリスト」を作るんだ。
だから、`tags @> ‘{“postgres”}’` みたいなクエリを投げると、GINは瞬時に「あ、これを持ってるのはID: 1だね」って教えてくれる。これが爆速の理由だ。
でも、「代償」は小さくない
ここからが本題だ。GINが優れているのは「検索」だけ。実は、「更新」には滅法弱いんだよ。
1. 更新コストが重い理由
B-treeなら、データが1つ追加されたらインデックスのツリーを少し書き換えるだけで済む。でもGINは「転置インデックス」だから、配列やJSONの各要素を分解して、それぞれに対応するインデックスエントリを更新しなきゃいけない。
データが1回更新されるだけで、内部的にはインデックスに対して数倍〜数十倍の書き込みが発生することもある。これが続くと、インデックス自体が肥大化して、書き込みのたびにディスクI/Oが悲鳴を上げ始める。
2. 「Fast Update」という諸刃の剣
PostgreSQLには、この更新コストを緩和するために `fastupdate` という設定がある（デフォルトでONだ）。これは更新を即座にインデックスに反映せず、一度メモリ上の「pending list」に溜め込んで、後でまとめて処理する仕組みだ。
書き込みは速くなるけど、「検索時にpending listもスキャンする必要がある」から、溜まりすぎると今度は検索性能が落ちる。まさにトレードオフだね。
—
実践：GINを「賢く」使うための3つの作法
じゃあ、現場でどう使い分けるべきか。僕の経験則を伝授するよ。
① `jsonb_path_ops` を検討する
デフォルトのGIN演算子クラスは、JSONBの全要素をインデックス化するから汎用的だけど、サイズが大きくなりがちだ。もし検索パターンが固定されているなら、`jsonb_path_ops` を使ってみてほしい。
— 通常のGIN
CREATE INDEX idx_data ON my_table USING GIN (data);
— jsonb_path_opsを使ったGIN（検索が圧倒的に速くなることが多い）
CREATE INDEX idx_data_path ON my_table USING GIN (data jsonb_path_ops);
`jsonb_path_ops` はハッシュ値を使ってインデックスを作るから、インデックスサイズが小さくなり、検索も速くなる。ただし、`@>` 演算子しか使えなくなるから、要件と相談だね。
② 更新が頻繁なら、いっそ分離する
もし「頻繁に更新されるが、検索もしたい」というテーブルなら、インデックスを貼るカラムを慎重に選ぼう。JSONB全体をGINにするんじゃなくて、必要なパスだけを抽出した計算インデックスを作るのも手だ。
— 必要なタグだけをインデックス化
CREATE INDEX idx_tags ON my_table USING GIN ((data->’tags’));
これなら、`data` 全体の更新に引きずられてインデックスが再構築されるのを防げる。
③ pending list の様子を監視する
運用に入ったら、このクエリをたまに叩いてみてくれ。
SELECT count() FROM gin_pending_list_memused(‘idx_your_index_name’);
もしこれが常に膨らんでいるようなら、`fastupdate = off` にして、夜間のメンテナンスバッチで `VACUUM` を回す方がシステム全体の安定感は増すはずだ。
—
最後に：銀の弾丸はない
GINは、検索性能を劇的に引き上げる素晴らしい機能だ。でも、「とりあえずGIN貼っておけばOK」という思考停止が、数ヶ月後のシステム障害を引き起こすことはよくある。
「このカラムの更新頻度は？」「検索クエリはどんなパターンで来る？」「データ量は今後どれくらい増える？」
こういったことを設計段階で想像できるのが、一流のエンジニアへの第一歩だよ。もし困ったら、`EXPLAIN ANALYZE` を取って、インデックスが本当に使われているか、あるいは逆に更新を邪魔していないかを確認することから始めてみてくれ。
また何か詰まったら、いつでも聞きに来なよ。現場からは以上だ！
コメント