【テクニカル・上級編】 tsvector型と全文検索 – PostgreSQL

PostgreSQLで全文検索を実装する際、まず手にするのが `tsvector` だろう。多くのエンジニアは、とりあえず `to_tsvector` を叩いて、`@@` 演算子で検索して「便利だ」と満足する。

だが、システムの規模が大きくなり、数千万行のドキュメントを扱うようになると、その「便利さ」の裏側にあるコストが牙を剥く。今日は、PostgreSQLの全文検索を「ただの機能」としてではなく、データベースエンジンとしての挙動レベルで深掘りしてみようと思う。

`tsvector` を単なる「検索用のインデックス」だと思っているなら、それは少し認識を改めたほうがいい。内部的には、`tsvector` はトークン（語彙）のソート済みリストであり、それぞれに位置情報（position）や重み（weight）が付与された構造体だ。

SELECT to_tsvector(‘english’, ‘The quick brown fox jumps over the lazy dog’);
— 結果例: ‘brown’:3 ‘dog’:9 ‘fox’:4 ‘jump’:5 ‘lazi’:8 ‘quick’:2

この「位置情報」こそが重要だ。なぜなら、PostgreSQLは単に「単語が含まれているか」を判定するだけでなく、`ts_rank` や `ts_headline` を使った近接性検索やスニペット生成を、インデックスの情報を参照するだけで（あるいはヒープへのアクセスを最小限にして）実行できるからだ。

全文検索を爆速にするには `GIN (Generalized Inverted Index)` が不可欠だ。しかし、GINは「書き込みの代償」が非常に大きい。

GINは、各トークンがどの行（TID）に含まれているかを保持するインバーテッドインデックスだ。ドキュメントを更新するたびに、その中にあるトークンすべてのエントリを更新しなければならない。

パフォーマンストラブルの種: 更新頻度が高いテーブルに巨大な `tsvector` カラムを置くと、インデックスの肥大化と更新競合（Lock contention）で死ぬ。
対策:
`fastupdate` を適切に設定する（ただし、検索速度と引き換えになる）。
あるいは、検索対象のテーブルと検索インデックス用のテーブルを分離し、トリガーで非同期的に更新する設計を検討する。

時折、「なぜか全文検索がフルスキャンになる」という相談を受ける。その多くは、クエリの書き方が原因だ。

`tsvector` を検索する際、`to_tsquery` で生成されたクエリが「前方一致」を意図したワイルドカードを含んでいたり、逆にクエリ側のトークン化設定（`tsconfig`）が、インデックス作成時の設定と微妙にずれていたりすると、インデックスは役に立たない。

特に注意すべきは、日本語検索などで `pg_bigm` を使わず、`tsvector` で強引に実装しようとするケースだ。`tsvector` は言語特有のステミング（語幹抽出）に依存する。辞書設定が不一致なら、検索結果はスカスカになるし、インデックスも当然ヒットしない。

巨大なテーブル全体に `GIN` を張るのではなく、必要な部分だけを切り出す「部分インデックス（Partial Index）」は、メモリ効率を劇的に改善する。

CREATE INDEX idx_fts_search ON articles USING GIN(to_tsvector(‘english’, body))
WHERE status = ‘published’;

これだけで、検索対象のインデックスサイズを半分以下に抑え、キャッシュ効率を跳ね上げられる。また、特定のカラムの組み合わせを一つの `tsvector` に集約してインデックス化する「式インデックス」も、読み取り性能を最大化する定石だ。

全文検索において、「これで完璧だ」という正解はない。テキストの言語、更新頻度、検索の要求精度、これら全てのバランスをアーキテクチャに落とし込むのが僕らの仕事だ。

もし今、全文検索の遅延に悩んでいるなら、まずは `EXPLAIN (ANALYZE, BUFFERS)` を見てほしい。どこでインデックスが外れ、どこでヒープを叩いているのか。その「声」を聞けば、次に何をすべきかは自ずと見えてくるはずだ。

データベースは、エンジニアの設計意図を最も正直に反映する鏡のようなものだ。その鏡を、可能な限りクリアに磨き続けていこう。