Postgresにおける全文検索: Elasticsearch vs. 代替手段

 (blog.paradedb.com)
22 ポイント 投稿者 xguru 2024-08-14 | 3件のコメント | WhatsAppで共有

全文検索 (Full Text Search)

  • 全文検索は、特定のキーワードやフレーズの有無に基づいてテキスト集合から項目を見つける技術
  • Elasticsearch のようなほとんどの検索エンジンは、検索結果を順位付けするために BM25 アルゴリズムを使用
    • BM25 は、用語がどれだけ頻繁に現れるか、そしてその用語が全ドキュメントの中でどれだけ固有かを考慮する
  • 全文検索は、意味的な意味に基づいて結果を検索・順位付けする類似検索やベクトル検索とは異なる
  • 多くの最新アプリケーションは全文検索と類似検索を組み合わせて使用しており、これをハイブリッド検索と呼び、より正確な結果を得られる

Postgres FTS

メリット

  1. シンプルさ

    • Postgres FTS は追加のインフラを必要とせず、AWS RDS のようなあらゆるマネージド Postgres サービスで利用できる
    • 長期的には外部検索エンジンをオーケストレーションして管理する必要がなくなり、かなりの時間と労力を節約できる

  2. リアルタイム検索

    • Postgres FTS では、コミット直後にデータを検索できる
    • これは、ユーザー向け検索体験やレイテンシに敏感な検索体験を構築する企業（例: EC サイトやフィンテック）にとって非常に有用

  3. Postgres トランザクションと MVCC

    • Postgres の ACID トランザクションと多版同時実行制御（MVCC）は、同時アクセスや頻繁な更新時にも FTS 結果の信頼性を保証する

デメリット

  1. 機能の不十分さ

    • Postgres FTS の限られた機能セットは、一部の企業にとっては決定的な欠点になり得る
    • 欠けている機能には、BM25 スコアリング、関連度調整、カスタムトークナイザー、ファセットなどがある

  2. 大規模データセットでの性能低下

    • Postgres FTS は数百万行のテーブルでは十分に機能するが、数千万行のテーブルでは性能が大きく低下する

  3. トランザクションのオーバーヘッド

    • カラムに GIN インデックスを作成すると、そのカラムに影響するトランザクションにわずかなレイテンシ（通常はミリ秒単位）が追加される

要点

  • Postgres FTS は、高度な FTS クエリを必要としない小〜中規模テーブルの検索に最適
  • 「中規模」や「高度」が何を意味するかは意図的に曖昧で、性能要件によって異なる
  • 幸い、Postgres FTS への/からのテストや移行は非常に簡単

Elasticsearch

メリット

  1. 包括的な機能セット

    • Elasticsearch はほぼあらゆる FTS クエリを処理できる
    • Elastic Query DSL（ドメイン固有言語）は全文検索機能の標準

  2. 高い性能

    • ベンチマークによれば、Elasticsearch は中核となる実戦投入済みの Lucene 検索エンジンと分散アーキテクチャにより、数十億行をミリ秒単位でクエリできる

  3. 検索以外の機能

    • FTS に加えて、Elasticsearch は分析クエリエンジン、ベクトルデータベース、セキュリティおよびオブザーバビリティのプラットフォームでもある
    • 多くの組織は、複数のサービスを Elasticsearch 内に統合できるシンプルさを享受している

デメリット

  1. 信頼できるデータストアではない

    • 多くの企業では、Elasticsearch を主要なデータストアとして使うと決めたことを後悔した例がある
    • これは推奨されない使い方である。Elasticsearch には ACID トランザクションや MVCC がなく、データ不整合や損失が発生し得るほか、リレーショナルな性質やリアルタイム整合性に欠けるため、多くのデータベースクエリが難しい

  2. ETL パイプラインが必要

    • Elasticsearch は信頼できるデータストアではないため、通常 Postgres を使う組織は Postgres から Elasticsearch へデータを抽出・変換・ロード（ETL）する
    • ETL パイプラインの障害はさまざまな本番停止につながり得るため、基盤となる Postgres スキーマの変更がパイプラインを壊さないよう慎重な保守が必要

  3. データ鮮度の低下

    • ETL ジョブは時間がかかり、定期的に実行される
    • Elasticsearch に届くデータは、しばしば Postgres より数時間遅れる
    • Postgres テーブルに対してリアルタイム検索を行うアプリケーションにとって、これは致命的になり得る

  4. コスト

    • 複数の企業から、Elasticsearch が最大のソフトウェア費用項目になったという話を聞くのは驚きだ
    • Elasticsearch クラスタのコストが急増するにつれ、多くの企業は Elasticsearch Cloud からセルフホスト運用へ移行したが、これはクラウド支出を減らした一方で新たな問題を生んだ
    • Elasticsearch は運用・チューニング・管理が非常に難しいことで悪名高い
    • こうした組織は、Elasticsearch クラスタを管理するために高コストなエンジニアを雇用している

要点

  • Elasticsearch は、運用オーバーヘッドとデータ鮮度を犠牲にして優れた検索性能を提供する
  • より軽量な代替手段では不可能な場合、あるいは他の Elasticsearch サービスも使う予定がある場合には Elasticsearch を推奨

代替検索エンジン

  • ここ数年で、Algolia、Meilisearch、Typesense のようなモダンな検索エンジンが登場した
  • これらのエンジンは一般に、ユーザー向けの検索体験を構築するために使われる
  • Hacker News 検索も Algolia 上に構築されている
  • 各サービスにはそれぞれ差別化要素があるが、Postgres 向け検索を探す開発者にとって重要な注意点がある
  • これらのソリューションはいずれも Postgres のために特化して構築されたものではない
  • Postgres ユーザーは、Elasticsearch と同様にこれらのサービスでも似た問題を経験する可能性がある

いいとこ取りは可能か?

  • ParadeDB は Postgres のために構築された全文検索エンジン
  • pg_search という拡張をベースに、ParadeDB は Rust ベースの Lucene 代替である Tantivy を Postgres 内部に組み込んでいる
  • Postgres FTS と同様に、ParadeDB は追加インフラなしで既存のセルフホスト型 Postgres データベースに接続する
  • Elasticsearch と同様に、ParadeDB は高度な全文検索エンジンの機能を提供する
  • Amazon RDS のようなマネージド Postgres サービスとの互換性も近日提供予定

関連記事

3件のコメント

 
galadbran 2024-08-14

Postgres FTSって何かと思ったら、組み込み機能のことだったんですね
 
xguru 2024-08-14

この人たちは継続的に改善を進めながら関連する記事を公開していて、GeekNewsでも何度も共有しました。

ParadeDB - PostgreSQL for Search
pg_bm25 - PostgresでElasticレベルの品質を提供するフルテキスト検索拡張
 
cometkim 2024-08-14

記事で言及されている paradedb、pg_search、pg_bm25 は、いずれも同じプロジェクトです。