ParadeDB、PlanetScaleのTIN発表を受けて検索パフォーマンスを大幅に改善
ParadeDB Search Performance Improvements
PlanetScaleがPostgres向け全文検索拡張機能TINを発表し、ParadeDBのBM25ランキング検索と文書数カウント機能に対して大幅なパフォーマンス向上を報告した。これに対し、ParadeDBは2週間でパフォーマンス改善に取り組み、同じStackExchangeベンチマークデータセット、ハーネス、マシンタイプを使用した場合、TINのベンチマーク結果(ParadeDB 0.25の8倍以上高速)のギャップをほぼ解消した。ParadeDBの改善点は、フィールドノルムの局所性向上によるランダムアクセス削減、およびBlockmax WANDループの最適化(MAXSCOREパスの実装)による多数のタームを含むクエリの高速化である。また、PlanetScaleのベンチマークにおけるParadeDBの構文の誤り(複数のフィールドを検索していた)や、TINの共通語に対するスコアリングショートカット(dense-term elision)がParadeDBに不利に働いていた点を指摘している。ParadeDBは、文書識別子としてctidではなくu32 DocIdを使用し続けることを選択しており、これはカラム型ストレージとの連携において利点があると説明している。これらの最適化はTantivyライブラリに組み込まれ、ParadeDB 0.26.0で提供される予定である。
- PlanetScaleがPostgres向け全文検索拡張TINを発表し、ParadeDBのBM25ランキング検索および文書カウントに対して大幅な性能優位を報告した
- ParadeDBは2週間で最適化に取り組み、同一StackExchangeベンチマーク・同一ハーネス・同一マシンタイプでTINとの性能差をほぼ解消した(TINの結果はParadeDB 0.25比で8倍以上高速だった)
- 改善内容はフィールドノルムの局所性向上によるランダムアクセス削減と、Blockmax WANDループへのMAXSCOREパス実装によるマルチタームクエリ高速化
- PlanetScale側ベンチマークにはParadeDBのクエリ構文誤り(複数フィールドを検索)とTINのdense-term elision(共通語のスコアリングショートカット)という不利条件が含まれていたとParadeDBが指摘
- ParadeDBは文書識別子にctidではなくu32 DocIdを使い続ける方針を維持し、カラム型ストレージとの連携上の利点を主張している
- 最適化はTantivyライブラリに取り込まれ、ParadeDB 0.26.0で提供予定
DB検索エンジン性能はPostgresエコシステムの競争軸になりつつあり、PlanetScaleのTIN対抗でParadeDBが2週間でベンチマーク差をほぼ解消した点は、OSSベースの検索拡張が短期間でキャッチアップ可能なことを示す。性能差が縮まれば差別化は運用・エコシステム・マネージド提供力に移るため、PlanetScaleの優位が技術的優位でなくブランド/統合優位に限定されるリスクと、ParadeDB 0.26.0/Tantivyへの改善取り込みによる採用拡大余地を注視したい。ただし投資判断に直結する資金・契約・規制情報は本記事に含まれない。