`ts_headline`の裏側：検索体験を最適化する「最後のピース」
PostgreSQLで全文検索を実装する際、多くのエンジニアが `tsvector` と `tsquery` の組み合わせで「何がヒットしたか」を特定するところまでは辿り着きます。しかし、その先の「検索結果のプレビューをどう見せるか」というUI/UXの観点に立ったとき、多くの人が `ts_headline` 関数に突き当たることになるはずです。
公式ドキュメントにはさらっと書かれていますが、この関数、実は単なる文字列処理のツールではありません。大規模なデータセットでこれを多用すると、往々にして「なぜかクエリが遅い」「CPU負荷がスパイクする」といったトラブルを引き起こします。
今日は、`ts_headline` の内部挙動と、本番環境でこれを「正しく」使いこなすための勘所について、少し踏み込んでお話ししましょう。
—
なぜ `ts_headline` は重くなるのか
`ts_headline` が行っている処理を解像度を上げて見ると、実はかなり過酷なことをしています。
1. トークナイズと正規化の再実行:
インデックス（GINなど）はトークン化された後の状態で保存されていますが、`ts_headline` は、元のテキスト（あるいは `text` 型のデータ）を再度解析し、クエリと照合して「どこをハイライトすべきか」を計算します。
2. スライディングウィンドウの計算:
単にマッチした箇所を抜粋するだけでなく、前後のコンテキスト（デフォルトで35語程度）を切り出し、一つの文字列として連結する処理が必要です。これが100件、1000件のリストに対して走ると、メモリ消費とCPUリソースを激しく叩くことになります。
特に、`StartFragment` や `StopFragment` などのパラメータを複雑に指定し、かつ `MaxFragments` を大きく設定している場合、検索結果が数万件ヒットするようなクエリでこれを発行すると、データベースのワーカープロセスがスタックする様子を容易に想像できるはずです。
パフォーマンスの最適化：エンジニアとしての「妥協点」を見つける
もしあなたが、数百万件のレコードに対して `ts_headline` を無防備に投げているなら、設計を見直すべきです。以下のプラクティスを検討してみてください。
- 投影を制限する:
`ts_headline` は必ず「検索結果の表示に必要な件数分だけ」実行するようにしてください。ページネーションを噛ませて、例えば `LIMIT 20` された結果に対してのみ関数を適用するのが鉄則です。
- 計算の外部化とキャッシュ:
もし頻繁に検索されるクエリがあるなら、`ts_headline` の結果を検索のたびに計算させる必要はありません。Redisなどの外部キャッシュに「検索クエリ＋文書ID」をキーとしてスニペットを格納し、初回以降はそれを引くというアプローチは、大規模サイトでは標準的な設計です。
- テキストの分割:
一つのカラムに巨大なテキストを詰め込んでいる場合、`ts_headline` はその全体をスキャンしようとします。文書を論理的に分割して保持しておくか、あるいは `ts_headline` を適用する対象のテキストを、あらかじめ適度な長さにトリミングしておく前処理が、実は一番効きます。
隠れた罠：言語設定と設定の不一致
トラブルシューティングで一番多いのが、「`ts_headline` の結果が期待したハイライトにならない」という相談です。
これの多くは、インデックス作成時に使用した `regconfig`（例: `english` や `japanese`）と、`ts_headline` 実行時に指定するコンフィグが一致していないことに起因します。`ts_headline` は、内部で再度トークナイザーを動かすため、ここがズレていると、検索はヒットしているのにハイライトされない、あるいは意図しない位置で断ち切られるといった現象が起きます。
— よくあるミス：第3引数を省略してデフォルト設定で動かしている
SELECT ts_headline(‘english’, body, to_tsquery(‘english’, ‘PostgreSQL’)) FROM docs;
第1引数に明示的に適切な辞書を指定することは、安定した検索体験を構築するための「作法」です。
—
最後に：データベースは「検索エンジン」ではない
PostgreSQLの全文検索機能は非常に強力ですが、あくまでRDBの機能です。Elasticsearchのような専用エンジンと比較すれば、ハイライト処理の柔軟性やパフォーマンス特性には明確な限界があります。
「どこまでをRDBにやらせ、どこからをアプリケーション層やキャッシュ層に逃がすか」。その境界線を設計するのが、我々エンジニアの腕の見せ所です。`ts_headline` が重いと感じたときは、ぜひその「境界線」を見直してみてください。
さて、次は `ts_rank` を用いたランキングアルゴリズムの調整について、もう少し深い話をしてみようかと思います。またお会いしましょう。
コメント