【テクニカル・上級編】 全文検索ランキング – PostgreSQL

PostgreSQLで「検索体験」を極める：ts_rankとハイライトが描く最適解

PostgreSQLの全文検索機能（Full Text Search）を、単なる「`LIKE`検索の代わり」として使っているなら、それは非常にもったいない。

実務で数千万件規模のドキュメントを扱うようになると、インデックスを貼るだけでは不十分だという壁に突き当たるはずだ。「関連度の高い順に並べたい」「どこにヒットしたかユーザーに伝えたい」――このニーズに応えるのが `ts_rank`、`ts_rank_cd`、そして `ts_headline` だ。

今回は、これらを単なる関数としてではなく、パフォーマンスとUXを両立させるための「武器」としてどう使いこなすべきか、現場の視点で語っていこうと思う。

—

関連度スコアリングの深淵：ts_rank vs ts_rank_cd

PostgreSQLで検索順位を制御する際、まず手に取るのが `ts_rank` だ。だが、中級者から一歩先へ進むなら、そのアルゴリズムの差を理解しておく必要がある。

ts_rank：頻度に基づくシンプルな指標

これは非常に直感的だ。ドキュメント内でキーワードが何回出現したかを重視する。実装が軽く、単純なキーワードマッチングには適している。しかし、文章が長ければ長いほど「たまたまキーワードが多いだけの無関係な記事」が上位に浮上しやすいという弱点がある。

ts_rank_cd：近接性（Cover Density）という視点

僕が現場で好んで使うのは、こちらの `ts_rank_cd` だ。これは「キーワード同士がどれだけ近くに存在するか」という、いわゆる近接性を考慮してくれる。
例えば「PostgreSQL」「パフォーマンス」「チューニング」という3語を検索した際、それらが文中でバラバラに存在するよりも、ひとまとまりの文節として存在している方が、ユーザーの意図に近い可能性が高い。

実務的な注意点：
`ts_rank_cd` は計算コストが高い。巨大な結果セットに対して `ORDER BY` で直接実行すると、クエリプランナが悲鳴を上げることがある。解決策としては、あらかじめ `tsvector` カラムに重み付けをしておくことだ。`setweight` 関数を活用して、タイトルには ‘A’、本文には ‘D’ といった重みを付与し、その重みを考慮した `ts_rank` を計算させるのが、スケーラビリティを確保する定石だ。

—

ts_headline：UXとパフォーマンスのトレードオフ

検索結果のハイライト表示を行う `ts_headline` は、ユーザーにとって「何がヒットしたのか」を可視化する最強のツールだが、同時にクエリのCPU負荷を跳ね上げる主犯格でもある。

なぜ重いのか？

`ts_headline` は、検索結果を表示するたびに、元のテキストから該当箇所を切り出し、エスケープ処理を施し、タグで囲むという計算を行っている。これをページネーションの全件に対して実行すると、当然ながらレスポンスタイムは悪化する。

賢いハイライト戦略

• 計算は「結果セットのみ」に絞る：

クエリ全体で `ts_headline` を呼ぶのではなく、ページングされた特定の行（`LIMIT` された結果）に対してのみ適用するよう、副問い合わせや共通テーブル式（CTE）で工夫する。

• スタブ化の検討：

もしテキストが極端に長い場合、`MaxFragments` や `MinWords` パラメータを絞り込み、処理量を意図的に減らすこと。デフォルトのままで運用するのは、特にモバイル環境では命取りになりかねない。

—

パフォーマンストラブルシューティングの勘所

もし本番環境で「検索が遅い」と言われたら、まずは以下の順序で確認してほしい。

1. インデックスの有効性確認： `EXPLAIN ANALYZE` を叩け。`Bitmap Index Scan` が発生しているか？ もし `Seq Scan` になっていたら、`tsvector` カラムのインデックス（GINまたはGiST）が適切に機能していない。
2. 正規化の不一致： 検索クエリ（`to_tsquery`）とインデックス時の設定（`to_tsvector`）の辞書（言語設定）がズレていないか。これが一致していないと、インデックスは一切使われない。
3. 演算子のオーバーヘッド： `ts_rank` を `ORDER BY` に入れると、全件のスコア計算が走る。数万件以上の検索結果がある場合は、`LIMIT` をかけるのはもちろん、可能であればスコアリングをアプリケーションレイヤーに逃がすか、あるいはElasticsearchのような検索エンジンへの移行も視野に入れるべきだ。

—

最後に：データベースは「検索エンジン」ではない

PostgreSQLの全文検索機能は、驚くほど高機能で、多くの小・中規模アプリケーションにはこれで十分すぎるほどだ。しかし、データベースエンジニアとしてあえて言うならば、「検索のUXを突き詰めすぎてDBの負荷を上げすぎるな」ということだ。

DBはデータの整合性を守る場所であり、検索体験を追求する場所ではない。もし「検索の関連度」がビジネスの核心（ECサイトの検索ロジックなど）になるなら、PostgreSQLで検索の基礎を作りつつ、複雑な順位付けが必要になった時点で外部の検索エンジンへオフロードする――この引き際を見極めるのが、真のプロフェッショナルの判断だと思う。

技術は常にバランスだ。最高のデータベースで、最高の検索体験を構築してほしい。応援している。