全文検索の「沼」にハマる前に：ts_rankの内部構造とパフォーマンス最適化の勘所
PostgreSQLで全文検索を実装する際、`tsvector`と`tsquery`の組み合わせで「とりあえず動く」ところまでは誰でも辿り着ける。しかし、いざ本番環境で数百万件のレコードを相手にすると、クエリのレスポンスが牙を剥く。特に`ts_rank`を使ったランキングソートは、インデックス設計を疎かにすると一瞬でシステムを麻痺させる爆弾になり得る。
今日は、ただの関数の使い方ではなく、なぜ`ts_rank`が遅くなるのか、そしてどうやってそれをねじ伏せるのかについて、少し深掘りしてみよう。
ts_rankの正体：重み付け計算の舞台裏
`ts_rank`関数が何をしているかというと、実はシンプルだ。`tsvector`内の各トークン（lexeme）に対して、出現頻度と、事前に定義された「重み（A, B, C, D）」に基づいたスコアリングを行っているに過ぎない。
内部的には、以下の計算式に近い処理が走っている。
$$rank = \sum \frac{(weight\_factor \times frequency)}{log(distance\_to\_other\_tokens)}$$
ここで重要なのは、`ts_rank`は計算コストが高いという点だ。PostgreSQLはクエリを実行する際、マッチした全行に対してこの計算をオンメモリで行おうとする。小規模なテーブルなら誤差だが、数百万行のテーブルで「検索結果をスコア順で上位20件出す」という処理を投げると、PostgreSQLはクエリプランナの制約を超えて、CPUを焼き尽くすほどの計算を強いられることになる。
よくある地雷：インデックスを使わないソート
多くのエンジニアが犯すミスは、`ts_rank`の結果に対して`ORDER BY`をかけ、そのままページネーション（LIMIT/OFFSET）を行うことだ。
SELECT title, ts_rank(text_vec, query) as rank
FROM documents
WHERE text_vec @@ query
ORDER BY rank DESC
LIMIT 20 OFFSET 1000;
これを見ると、PostgreSQLは「全文検索のインデックス（GIN）」を使って絞り込みは行っている。しかし、ソートのために全マッチ行のスコアを計算しなければならない。もし検索ワードが一般的すぎてマッチ数が10万件あったら？ 10万回もの重み付け計算が実行され、さらにソート処理が走る。これはパフォーマンスとしては最悪のシナリオだ。
パフォーマンスを改善するための「二段構え」戦略
この沼を脱出するためのアプローチはいくつかあるが、私が現場でよく使うのは以下の手法だ。
1. 探索範囲の限定（Materialized Viewの活用）
もし検索対象が頻繁に更新されないなら、スコア計算の一部を事前に済ませる戦略がある。あるいは、直近のデータに重みを置くような「減衰関数」を組み合わせて、`WHERE`句で最初から検索範囲を絞り込む。
2. パーシャルインデックスと演算子クラスの再考
GINインデックスは強力だが、`ts_rank`の計算には何の恩恵も与えない。もしパフォーマンスがどうしても出ないなら、検索対象のテキストをいくつかのカテゴリーに分割し、`PARTITION BY`を駆使して、検索対象のインデックスを物理的に分割する。これにより、スコア計算が必要なレコード数を物理的に減らすことができる。
3. 「近似値」での妥協
ビジネス要件と相談する必要はあるが、厳密なランク付けが本当に必要か自問してほしい。
- 全件ソートするのではなく、`LIMIT`を小さくして、最初の数件だけを計算させる。
- 頻出する単語については、`ts_rank_cd`（カバレッジ密度ベースのランキング）を使いつつ、インデックスでカバーできない複雑なクエリを排除する。
最後に：エンジニアとしての矜持
全文検索の実装は、データベースという黒い箱と対話するようなものだ。`ts_rank`は非常に優秀だが、裏側で何が起きているか（CPUサイクルがどう消費され、メモリがどう確保されているか）を想像できないと、いずれ必ず痛い目を見る。
「とりあえず動く」コードから、「負荷を計算できる」コードへ。それが、フルスタックなデータベースエンジニアへの入り口だ。もし今、あなたの環境で`ts_rank`がCPUを占有しているなら、まずは`EXPLAIN (ANALYZE, BUFFERS)`を叩いてみてほしい。そこで見える「フィルタリング」のコストが、あなたの次の改善のヒントになるはずだ。
技術は裏切らない。ただ、無知に対しては容赦がない。また次の現場で会おう。
コメント