69

全文検索が必要なRailsアプリをHerokuにデプロイする準備をしています。これまで、MySQLとSphinxを使用してVPSで実行してきました。

ただし、HerokuでSphinxまたはSolrを使用する場合は、アドオンの料金を支払う必要があります。

PostgreSQL（Herokuで使用されるDB）には全文検索機能が組み込まれていることに気付きました。

Postgresの全文検索を使用できなかった理由はありますか？Sphinxより遅いですか、それとも他の大きな制限がありますか？

4

6 に答える 6

77

編集、2016 —なぜ両方ではないのですか？

PostgresとLuceneに興味があるなら、両方ではないのはなぜですか？ファーストクラスのインデックスタイプとしてElasticsearchを統合するPostgresのZomboDB拡張機能を確認してください。まだかなり初期のプロジェクトですが、私には本当に有望に見えます。

（技術的にはHerokuでは利用できませんが、それでも一見の価値があります。）

開示：私はWebsolrとBonsai Herokuアドオンの共同創設者なので、私の見方はLuceneに少し偏っています。

Postgresの全文検索について読んだところ、単純なユースケースではかなり堅実ですが、Lucene（したがってSolrとElasticSearch）がパフォーマンスと機能の両方の点で優れている理由はいくつかあります。

手始めに、jpountzは、 「SolrがPostgresよりもはるかに高速なのはなぜですか？」という質問に対する真に優れた技術的回答を提供します。本当に消化するために、2、3回読む価値があります。

また、Postgres全文検索とSolrの相対的な長所と短所を比較した最近のRailsCastエピソードについてもコメントしました。ここで要約します。

Postgresの実用的な利点

  • 他の何かをセットアップして維持（または料金を支払う）する代わりに、すでに実行している既存のサービスを再利用します。
  • 素晴らしく遅いSQLLIKE演算子よりもはるかに優れています。
  • すべて同じデータベースにあるため、データの同期を維持する手間が少なくなります。アプリケーションレベルで一部の外部データサービスAPIと統合する必要はありません。

Solr（またはElasticSearch）の利点

頭のてっぺんから、順不同で…</ p>

  • 通常のデータベースの負荷とは別に、インデックス作成と検索の負荷をスケーリングします。
  • アクセントの正規化、言語ステミング、Nグラム、マークアップの削除などのより柔軟な用語分析…スペルチェック、「リッチコンテンツ」（PDFやWordなど）の抽出などの他の優れた機能…</ li>
  • Solr / Luceneは、Postgres全文検索TODOリストのすべてを問題なく実行できます。
  • 検索時に効率的にカスタマイズ可能な、はるかに優れた高速な用語関連性ランキング。
  • 一般的な用語や複雑なクエリの検索パフォーマンスはおそらく高速です。
  • おそらくPostgresよりも効率的なインデックス作成パフォーマンス。
  • プライマリデータストアからインデックスを切り離すことにより、データモデルの変更に対する許容度が向上します

明らかに、Luceneに基づく専用の検索エンジンがここでのより良いオプションだと思います。基本的に、Luceneは検索の専門知識の事実上のオープンソースリポジトリと考えることができます。

しかし、他の唯一のオプションがLIKE演算子である場合、Postgres全文検索は間違いなく勝利です。

于 2012-06-04T05:38:26.523 に答える
22

Elastic Search（1.9）をpostgres FTSと比較する作業を行ったばかりなので、結果は@gustavodiazjaimesが引用しているものよりもいくらか最新のものであるため、結果を共有する必要があると考えました。

postgresに関する私の主な懸念は、ファセットが組み込まれていないことでしたが、それは自分自身を構築するのは簡単です。これが私の例です（djangoで）：

results = YourModel.objects.filter(vector_search=query)
facets = (results
    .values('book')
    .annotate(total=Count('book'))
    .order_by('book'))

私はpostgres9.6とelastic-search1.9を使用しています（djangoのhaystackを介して）。これは、16のさまざまなタイプのクエリにわたるelasticsearchとpostgresの比較です。

    es_times  pg_times  es_times_faceted  pg_times_faceted
0   0.065972  0.000543          0.015538          0.037876
1   0.000292  0.000233          0.005865          0.007130
2   0.000257  0.000229          0.005203          0.002168
3   0.000247  0.000161          0.003052          0.001299
4   0.000276  0.000150          0.002647          0.001167
5   0.000245  0.000151          0.005098          0.001512
6   0.000251  0.000155          0.005317          0.002550
7   0.000331  0.000163          0.005635          0.002202
8   0.000268  0.000168          0.006469          0.002408
9   0.000290  0.000236          0.006167          0.002398
10  0.000364  0.000224          0.005755          0.001846
11  0.000264  0.000182          0.005153          0.001667
12  0.000287  0.000153          0.010218          0.001769
13  0.000264  0.000231          0.005309          0.001586
14  0.000257  0.000195          0.004813          0.001562
15  0.000248  0.000174          0.032146          0.002246
                  count      mean       std       min       25%       50%       75%       max
es_times           16.0  0.004382  0.016424  0.000245  0.000255  0.000266  0.000291  0.065972
pg_times           16.0  0.000209  0.000095  0.000150  0.000160  0.000178  0.000229  0.000543
es_times_faceted   16.0  0.007774  0.007150  0.002647  0.005139  0.005476  0.006242  0.032146
pg_times_faceted   16.0  0.004462  0.009015  0.001167  0.001580  0.002007  0.002400  0.037876

ファセット検索でこれらの速度に後戻りするために、SearchVectorFieldを使用してフィールドでGINインデックスを使用する必要がありました。これは、django固有ですが、他のフレームワークにも同様のベクトルタイプがあると確信しています。

もう1つの考慮事項は、9.6ページでフレーズマッチングがサポートされるようになったことです。これは非常に大きな問題です。

私の持ち帰りは、postgresはほとんどの場合それが提供するので好ましいだろうということです：

  1. よりシンプルなスタック
  2. 競合する検索バックエンドAPIラッパーの依存関係はありません（thinking-sphinx、django-sphinx、haystackなど）。これらは、検索バックエンドがサポートする機能（たとえば、干し草の山のファセット/集計）をサポートしていない可能性があるため、ドラッグになる可能性があります。
  3. 同様のパフォーマンスと機能を備えています（私のニーズに合わせて）
于 2016-10-04T14:50:32.217 に答える
16

私はこの驚くべき比較を見つけ、それを共有したいと思います：

PostgreSQLでの全文検索

インデックスLIKE述語を構築する時間-なし
PostgreSQL/GIN-40分
Sphinx検索-6分
ApacheLucene-9分
転置インデックス-高

インデックスストレージLIKE述語-なし
PostgreSQL/GIN-532MB
スフィンクス検索
-533MBApacheLucene-1071MB
転置インデックス-101MB

クエリ速度LIKE述語-90秒以上
PostgreSQL/GIN-20ミリ秒
Sphinx検索-8ミリ秒
ApacheLucene-80ミリ秒
転置インデックス-40ミリ秒

于 2013-05-20T04:06:11.763 に答える
3

Postgresの全文検索は、ステミング、ランキング/ブースト、同義語処理、あいまい検索などの分野で驚くべき機能を備えていますが、ファセット検索はサポートされていません。

したがって、Postgresがすでにスタックにあり、ファセットが必要ない場合は、Luceneベースのソリューションを探す前に、インデックスの同期と洗練されたスタックの維持が容易であるという大きなメリットを活用してみてください。アプリは検索に基づいていません。

于 2015-07-13T04:54:21.770 に答える
3

合成顧客データ（1,000万レコード）のいくつかのより新鮮な結果。

ここに画像の説明を入力してください

于 2020-02-26T08:14:33.323 に答える
1

PostgresqlのFTS関数は成熟しており、ルックアップでかなり高速です。確かに一見の価値があります。

于 2012-06-04T03:50:45.737 に答える