【実務・中級編】全文検索用GINインデックス – PostgreSQL

おい、みんな元気か！今日もバリバリとデータベースと格闘してるかな？

俺も最近、ちょっとした全文検索のパフォーマンス問題に直面しててね。もちろんPostgreSQLの全文検索機能は強力なんだけど、データ量が増えるとやっぱりインデックスは欠かせない。そこで今日は、全文検索の救世主とも言える「GINインデックス」について、現場の知見を交えながら深掘りしていこうと思うんだ。

「GINインデックス？ああ、なんかよくわかんないけど、とりあえず貼っとけってやつでしょ？」なんて思ってるそこの君、ちょっと待った！ただ貼るだけじゃもったいないし、なぜそれが必要なのか、どう使うのがベストなのかを知っておけば、いざという時に君の強力な武器になるからさ。

さあ、一緒にPostgreSQLの全文検索を爆速にする秘密を探っていこうぜ！

—

全文検索、その実態と課題

まず、PostgreSQLでの全文検索の基本的な流れを軽くおさらいしておこうか。

みんなも知ってる通り、PostgreSQLの全文検索は、テキストデータを`tsvector`型に変換して、それを`tsquery`で検索するのが基本だよね。

例えば、こんな感じで。

SELECT ‘これはPostgreSQLの全文検索のサンプルです’::tsvector @@ ‘PostgreSQL & 全文検索’::tsquery;
— 結果: t (真)

この`tsvector`に変換するってところがミソで、ストップワードの除去とか、ステミング（単語の語幹への変換）とか、PostgreSQLがよしなにやってくれるから、非常に強力なんだ。

でもさ、データが数百万行、数千万行って増えてくるとどうなると思う？
特定のキーワードを含む行を探すのに、毎回全行をスキャンして`tsvector`に変換してマッチングなんてやってたら、そりゃあ遅くなるに決まってるよね。ユーザーは検索結果を待ってくれないから、これじゃあ使い物にならない。

そこで登場するのが、今日の主役「GINインデックス」ってわけだ。

GINインデックスの登場！なぜ全文検索に効くのか？

「インデックス」って聞くと、B-treeインデックスが真っ先に思い浮かぶ人が多いんじゃないかな。主キーとか、よく検索条件に使うカラムに貼るやつね。B-treeは「この値はこの行にあるよ」っていうのを効率的に教えてくれる。

じゃあ、全文検索で必要なインデックスって何だろう？
それは、「この単語はどの行にあるか」を教えてくれるインデックスだ。1つのドキュメント（行）に複数の単語が含まれるから、B-treeみたいに単一の値に特化したインデックスじゃ対応しきれないんだよね。

そこでGIN（Generalized Inverted Index）インデックスの出番だ。
GINインデックスは、まさにその名の通り「転置インデックス」の一種なんだ。簡単に言うと、

1. ドキュメント（行）に含まれる単語をすべて抜き出す
2. 「この単語は、どのドキュメント（行）に含まれているか」というリストを作る

こんなイメージだ。例えば、

| 単語 | ドキュメントID |
| :——– | :————- |
| PostgreSQL | 1, 3, 5 |
| 全文検索 | 1, 2, 5 |
| インデックス | 2, 3, 4 |

こんな辞書みたいなものを作っておいて、ユーザーが「PostgreSQL」を検索したら、この辞書を引けばすぐにドキュメントID 1, 3, 5が見つかるってわけ。これなら数千万行あっても、単語を引くのは一瞬だろ？

これがGINインデックスが全文検索を高速化する基本的なメカニズムなんだ。

実践！GINインデックスを張ってみよう

じゃあ、実際にどうやってGINインデックスをPostgreSQLに作っていくか見ていこう。

まずは、サンプルとしてブログ記事を保存するテーブルを考えてみるよ。

CREATE TABLE blog_posts (
id SERIAL PRIMARY KEY,
title TEXT NOT NULL,
content TEXT NOT NULL,
created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP
);

この`title`と`content`に対して全文検索をかけたいとするよね。
そのために、まずは全文検索用の`tsvector`カラムを追加するのが一般的だ。こうすることで、検索ごとに`tsvector`を生成するコストを省けるし、インデックスを直接貼れるようになる。

ALTER TABLE blog_posts ADD COLUMN search_vector tsvector;

次に、この`search_vector`カラムを、`title`と`content`から自動的に更新されるようにトリガーを設定するのがスマートだ。

— 検索設定（日本語対応のため、pg_catalog.japaneseを使うのが一般的）
— もしインストールされてなければ CREATE EXTENSION pg_trgm; なども必要になる場合がある
— ここではデフォルトの設定で進めるが、日本語の全文検索は別途ちゃんと辞書設定が必要になるから注意してね！
— 参考: https://www.postgresql.jp/document/current/textsearch-dictionaries.html

CREATE FUNCTION update_blog_posts_search_vector() RETURNS TRIGGER AS $$
BEGIN
NEW.search_vector = to_tsvector(‘japanese’, NEW.title || ‘ ‘ || NEW.content);
RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER update_blog_posts_search_vector_trigger
BEFORE INSERT OR UPDATE ON blog_posts
FOR EACH ROW EXECUTE FUNCTION update_blog_posts_search_vector();

これで、`blog_posts`テーブルにデータを`INSERT`したり`UPDATE`したりすると、自動的に`search_vector`カラムが更新されるようになった。

いよいよGINインデックスの作成！

さて、いよいよ本命のGINインデックスだ。
PostgreSQLでGINインデックスを作成する際は、`tsvector`型に特化した演算子クラスを指定する必要があるんだ。それが`tsvector_ops`だ。

CREATE INDEX idx_blog_posts_search_vector ON blog_posts USING GIN (search_vector);

おっと、ちょっと待った！

この`CREATE INDEX`文、実は少しだけ不十分なんだ。PostgreSQLの全文検索用のGINインデックスでは、特別な演算子クラスを指定してあげる必要がある。それが`tsvector_ops`だ。

正しい書き方はこれだ！

CREATE INDEX idx_blog_posts_search_vector ON blog_posts USING GIN (search_vector tsvector_ops);

もし`tsvector_ops`を指定しないと、デフォルトの演算子クラスが適用されちゃうんだけど、それが`tsvector`型に対して必ずしも最適なインデックス構造を作ってくれるとは限らない。特に全文検索のパフォーマンスを最大限に引き出すためには、この`tsvector_ops`の指定が超重要なんだ。

データを入れてみよう

いくつかダミーデータを投入してみようか。

INSERT INTO blog_posts (title, content) VALUES
(‘PostgreSQLの全文検索を極める’, ‘この記事ではPostgreSQLの全文検索機能について詳しく解説します。インデックスの重要性もね。’),
(‘データベースチューニングの秘訣’, ‘PostgreSQLのパフォーマンスを向上させるためのヒントとテクニックを紹介します。’),
(‘Webアプリケーション開発入門’, ‘初めてWebアプリを作る人向けの基本的な情報をまとめました。’),
(‘GINインデックスで検索を高速化’, ‘全文検索の速度を劇的に改善するGINインデックスの使い方を実践的に解説します。’);

これで`search_vector`カラムも自動的に値が入っているはずだ。

SELECT id, title, search_vector FROM blog_posts;

実際に検索して、その効果を見てみよう！

インデックスを貼ったからには、その効果を確認しなきゃ意味がないよね。
`EXPLAIN ANALYZE`を使って、インデックスが使われているか、どれくらい速くなったかを見てみよう。

まずは、GINインデックスを使わない場合を想像してみてほしい。
（実際には`DROP INDEX`しないとインデックスは使われちゃうので、ここでは概念的な話ね）

— GINインデックスを一時的に無効化する（テスト目的で、実際にはあまりやらない）
SET enable_indexscan = off;
SET enable_bitmapscan = off;

EXPLAIN ANALYZE
SELECT id, title, content
FROM blog_posts
WHERE search_vector @@ to_tsquery(‘japanese’, ‘PostgreSQL & 全文検索’);

— 元に戻す
SET enable_indexscan = on;
SET enable_bitmapscan = on;

きっと`Seq Scan`（シーケンシャルスキャン、つまり全件スキャン）になって、大量のデータだと恐ろしく時間がかかるはずだ。

GINインデックスを使った検索

では、GINインデックスを有効にして、もう一度検索してみよう。

EXPLAIN ANALYZE
SELECT id, title, content
FROM blog_posts
WHERE search_vector @@ to_tsquery(‘japanese’, ‘PostgreSQL & 全文検索’);

この結果を見てほしい。

おそらく、`Bitmap Index Scan`や`Index Scan using idx_blog_posts_search_vector on blog_posts`といった表示が出ているはずだ。これは、PostgreSQLがちゃんとGINインデックスを使って検索している証拠だね。

そして、`Execution Time`が劇的に短くなっていることに気づくはずだ。データ量が増えれば増えるほど、この差は歴然となる。これがGINインデックスの威力なんだ！

`tsvector_ops`って何？なんで指定するの？

さっきさらっと流しちゃったけど、この`tsvector_ops`についてもう少し詳しく説明しておこうか。

PostgreSQLでは、インデックスを作成する際に「演算子クラス（Operator Class）」というものを指定できるんだ。これは、特定のデータ型や特定の操作に対して、どういうインデックス構造を使い、どうやって比較・検索するか、というルールを定義したものだと思ってくれればいい。

`tsvector`型の場合、デフォルトの演算子クラスは汎用的なものなので、全文検索のような特殊な（複数の単語を含む）データ構造や検索ロジックには最適化されていないんだ。

`tsvector_ops`は、まさに`tsvector`型のために特別に設計された演算子クラスだ。これを使うことで、GINインデックスが`tsvector`型のデータを「単語の集合」として効率的に格納し、`@@`演算子を使った全文検索を高速に実行できるように最適化されるんだ。

だから、全文検索用のGINインデックスを貼る時は、絶対に`tsvector_ops`を指定するのを忘れないでほしい。これを忘れると、「インデックス貼ったのに全然速くならないんだけど！？」ってことになりかねないからね。現場ではよくある落とし穴の一つだ。

さらにパフォーマンスを追求するヒント

GINインデックスを貼ったからといって、すべてが解決するわけじゃない。さらに一歩踏み込んで、パフォーマンスを最適化するためのヒントをいくつか紹介しよう。

1. `VACUUM`と`REINDEX`の重要性

GINインデックスは、データの更新（`INSERT`, `UPDATE`, `DELETE`）が多いと、内部的に「不要なエントリ」が溜まっていき、肥大化することがあるんだ。これが進むと、インデックス自体が重くなり、検索性能が劣化したり、ディスク容量を圧迫したりする。

`VACUUM`: 定期的に`VACUUM`（特に`VACUUM FULL`ではない`VACUUM`）を実行することで、インデックス内の不要なエントリをマークし、再利用可能な領域を増やすことができる。PostgreSQLのautovacuumデーモンが自動的にやってくれることが多いけど、大規模な更新があった後などは手動で実行することも検討しよう。
`REINDEX`: インデックスが大きく肥大化してしまった場合や、物理的な断片化が進んでしまった場合は、`REINDEX`コマンドでインデックスを再構築するのが効果的だ。`REINDEX INDEX idx_blog_posts_search_vector;`のように実行する。ただし、`REINDEX`中は対象インデックスへの書き込みがブロックされるため、本番環境での実行には注意が必要だ。PostgreSQL 12からは`REINDEX CONCURRENTLY`が使えるようになったので、ダウンタイムを最小限に抑えたい場合は検討しよう。

2. `tsvector`生成の最適化

トリガーで`search_vector`を生成する方法は一般的だけど、もし既存の巨大なテーブルに`search_vector`カラムを追加してインデックスを貼る場合、初回生成に時間がかかることがある。

大規模なデータに対しては、一度にすべての`search_vector`を更新するのではなく、バッチ処理で少しずつ更新したり、`pg_repack`のようなツールを使ってテーブルロックを回避しながらカラムを追加・更新したりする方法も検討してみよう。

また、`to_tsvector`の処理自体が重い場合もある。もし全文検索対象のテキストが非常に長大であれば、本当に必要な部分だけを`tsvector`に変換するように設計を見直すのも手だ。

3. パーサーと辞書のチューニング

俺たちが使ってる`to_tsvector(‘japanese’, …)`の`japanese`の部分は、PostgreSQLが提供する「設定」の名前なんだ。これには、どのパーサー（テキストを単語に分解する仕組み）を使い、どの辞書（ストップワードリストやステミングルール）を適用するかが含まれている。

日本語の全文検索は特に複雑で、デフォルトの`japanese`設定だけでは満足いく結果が得られないこともある。形態素解析エンジン（MeCabなど）をPostgreSQLと連携させたり、独自のストップワード辞書を作ったりすることで、検索精度やパフォーマンスをさらに向上させることができるんだ。

これはGINインデックスの話から少し外れるけど、全文検索システム全体を最適化する上では非常に重要なポイントだから、頭の片隅に置いておいてほしい。

まとめ

どうだったかな？今日はPostgreSQLの全文検索を爆速にするGINインデックスについて、その仕組みから具体的な使い方、そしてパフォーマンス最適化のヒントまで、現場で役立つ情報をみっちり解説してみたよ。

全文検索には`tsvector`と`tsquery`を使う。
大量のデータでの全文検索には、`GIN`インデックスが必須！
`CREATE INDEX … USING GIN (column tsvector_ops);` のように、`tsvector_ops`演算子クラスの指定を絶対に忘れないこと！
インデックスは貼って終わりじゃない。`VACUUM`や`REINDEX`で健全な状態を保ち、必要に応じて`tsvector`生成や辞書設定の最適化も検討しよう。

データベースのチューニングって、奥が深くて一見難しそうに見えるけど、一つ一つの技術をしっかり理解して実践すれば、君のサービスを支える強力な基盤になる。

今日の内容が、みんなのPostgreSQLライフの一助になれば嬉しいな。じゃあ、また次の記事で会おうぜ！頑張れよ！