web-dev-qa-db-ja.com

全文検索エンジンの比較-Lucene、Sphinx、Postgresql、MySQL?

Djangoサイトを構築していますが、検索エンジンを探しています。

少数の候補者:

  • Lucene/Lucene with Compass/Solr

  • スフィンクス

  • Postgresqlの組み込み全文検索

  • MySQlビルトイン全文検索

選択基準:

  • 結果の関連性とランキング
  • 検索とインデックス作成の速度
  • 使いやすさとDjangoとの統合のしやすさ
  • リソース要件-サイトは VPS でホストされるため、検索エンジンは多くのRAMおよびCPUを必要としません
  • 拡張性
  • 「という意味ですか?」、関連検索などの追加機能

上記の検索エンジン、またはリストに含まれていない他のエンジンの経験がある方は、ぜひご意見をお聞かせください。

編集:インデックス作成のニーズに関しては、ユーザーがサイトにデータを入力し続けると、それらのデータは継続的にインデックス化される必要があります。リアルタイムである必要はありませんが、理想的には15〜30分以内に新しいデータがインデックスに表示されます。

303
Continuation

Luceneについて誰かが口を閉ざしているのを見るのはいいことです。

一方、スフィンクスは非常によく知っているので、助けてくれるかどうか見てみましょう。

  • 結果の関連性ランキングがデフォルトです。必要に応じて独自のソートを設定し、特定のフィールドに高い重みを付けることができます。
  • インデックス作成速度は、データベースと直接通信するため、非常に高速です。速度の低下は、複雑なSQLクエリとインデックス化されていない外部キーなどの問題に起因します。私も検索の遅さに気付いたことはありません。
  • 私はRails男なので、Djangoを使用して実装するのがどれほど簡単かはわかりません。ただし、Sphinxソースに付属するPython AP​​Iがあります。
  • 検索サービスデーモン(searchd)のメモリ使用量はかなり低く、- メモリ量 インデクサープロセスも使用する制限を設定できます。
  • スケーラビリティは私の知識がもっと大雑把なところですが、インデックスファイルを複数のマシンにコピーしていくつかのsearchdデーモンを実行するのは簡単です。他の人から私が受ける一般的な印象は、それが高負荷の下でかなり良いということです。そのため、複数のマシンにスケールアウトすることは対処する必要のあるものではありません。
  • 「did-you-mean」などのサポートはありません-これらは他のツールで十分簡単に​​実行できますが。 Sphinxは辞書を使用して単語をステミングします。そのため、検索では「運転」と「ドライブ」は同じと見なされます。
  • ただし、Sphinxはフィールドデータの部分的なインデックス更新を許可しません。これに対する一般的なアプローチは、最近のすべての変更でデルタインデックスを維持し、変更のたびにインデックスを再作成することです(これらの新しい結果は1〜2秒以内に表示されます)。データ量が少ないため、これには数秒かかります。ただし、メインデータセットのインデックスを定期的に再作成する必要があります(ただし、データのボラティリティにどれだけ定期的に依存しますか-毎日ですか、毎時間ですか?)。ただし、インデックス作成の速度が速いため、これは非常に簡単です。

これがあなたの状況にどのように適用できるかわかりませんが、 Evan Weaverはいくつかの一般的なRails検索オプションを比較しました (Sphinx、Ferret(Ruby用Luceneのポート)およびSolr)、いくつかのベンチマークを実行しています。役に立つかもしれません。

私はMySQLの全文検索の深さを調べていませんが、Sphinx、Lucene、またはSolrと速度的にも機能的にも競合しないことを知っています。

163
pat

私はSphinxを知りませんが、Lucene対データベース全文検索に関しては、Luceneのパフォーマンスは比類のないものだと思います。 Luceneインデックスが正しく設定されていれば、検索するレコードの数に関係なく、10ミリ秒未満でほとんどany検索を実行できるはずです。

しかし、最大のハードルがここにあります:個人的に、Luceneをプロジェクトに統合することは簡単ではないと思います。もちろん、設定するのはそれほど難しくないので、基本的な検索を行うことができますが、最適なパフォーマンスで最大限に活用したい場合は、Luceneについての優れた本が間違いなく必要です。

CPUとRAMの要件については、Luceneで検索を実行してもCPUに負荷がかかることはありませんが、データのインデックス付けは頻繁に行いません(1日に1回または2回) 、それはそれほどハードルではありません。

すべての質問に答えるわけではありませんが、要するに、検索するデータが大量にあり、優れたパフォーマンスが必要な場合は、Luceneが間違いなく道だと思います。検索するデータがそれほど多くない場合は、データベースの全文検索を使用することもできます。私の本では、MySQL全文検索の設定が間違いなく簡単です。

82
Razzie

Solrについてこれ以上情報が投稿されていないことに驚いています。 SolrはSphinxと非常によく似ていますが、より高度な機能を備えています(私はSphinxを使用したことがないので、それについてのみ読んでください)。

以下のリンクの回答では、Sphinxについてのいくつかの詳細がSolrにも当てはまります。 フルテキスト検索エンジンの比較-Lucene、Sphinx、Postgresql、MySQL?

Solrは、次の追加機能も提供します。

  1. 複製をサポート
  2. 複数のコア(独自の構成と独自のインデックスを持つ個別のデータベースと考えてください)
  3. ブール検索
  4. キーワードの強調表示(regex-fuを使用している場合、アプリケーションコードでかなり簡単に実行できます。ただし、特別なツールでより良い仕事をさせてください)
  5. XMLまたは区切りファイルを介してインデックスを更新する
  6. HTTP経由で検索サーバーと通信します(Json、ネイティブPHP/Ruby/Pythonを返すこともできます)
  7. PDF、Wordドキュメントのインデックス作成
  8. 動的フィールド
  9. ファセット
  10. 集計フィールド
  11. ストップワード、シノニムなど。
  12. もっとこう...
  13. カスタムクエリを使用してデータベースから直接インデックスを作成する
  14. 自動提案
  15. キャッシュの自動ウォームアップ
  16. 高速インデックス作成(MySQL全文検索のインデックス作成時間と比較)-Luceneはバイナリ逆インデックス形式を使用します。
  17. ブースティング(特定のキーワードやフレーズの関連性を高めるためのカスタムルールなど)
  18. フィールド検索(検索ユーザーが検索したいフィールドを知っている場合、フィールド、次に値を入力して検索を絞り込み、すべてではなくそのフィールドのみを検索します-ユーザーエクスペリエンスが大幅に向上します)

ところで、たくさんの機能があります。ただし、実際に運用環境で使用した機能のみをリストしました。ところで、MySQLはデフォルトで、上記リストの#1、#3、および#11(制限付き)をサポートしています。探している機能については、リレーショナルデータベースはそれを削減しません。それらをすぐに削除します。

また、別の利点は、Solr(実際にはLucene)がドキュメントデータベース(たとえば、NoSQL)であるため、他のドキュメントデータベースの多くの利点がSolrで実現できることです。つまり、単なる検索(つまりパフォーマンス)以外にも使用できます。それで創造的になってください:)

60
Wil Moore III

現在、PostgreSQLの全文検索を検討していますが、最新の検索エンジンの適切な機能、非常に優れた拡張文字、多言語サポート、データベースのテキストフィールドとの緊密な統合があります。

しかし、+やAND(&|!を使用)などのユーザーフレンドリーな検索演算子はなく、ドキュメントサイトでの動作に興奮していません。結果スニペットに一致する用語が太字で表示されていますが、一致する用語のデフォルトのアルゴリズムは適切ではありません。また、rtf、PDF、MS Officeのインデックスを作成する場合は、ファイル形式コンバーターを見つけて統合する必要があります。

OTOH、これは3文字以下の単語のインデックスを作成しないMySQLテキスト検索よりもはるかに優れています。これはMediaWiki検索のデフォルトであり、エンドユーザーには良くないと思います: http://www.searchtools.com/analysis/mediawiki-search/

私が見たすべての場合において、Lucene/SolrとSphinxは本当に素晴らしいです。これらは堅実なコードであり、ユーザビリティが大幅に改善されて進化しているため、ツールはすべてのユーザーを満足させる検索を行うためにあります。

sHAILIの場合-SOLRにはLucene検索コードライブラリが含まれており、ニースのスタンドアロン検索エンジンになるコンポーネントがあります。

28
SearchTools-Avi

この非常に古い質問に対する私の2セントです。 ElasticSearch をご覧になることを強くお勧めします。

Elasticsearchは、Luceneに基づく検索サーバーです。 RESTful WebインターフェースとスキーマフリーのJSONドキュメントを備えた、分散型のマルチテナント対応フルテキスト検索エンジンを提供します。 ElasticsearchはJavaで開発されており、Apacheライセンスの条件の下でオープンソースとしてリリースされています。

他のFTS(全文検索)エンジンに勝る利点は次のとおりです。

  • RESTfulインターフェイス
  • より良いスケーラビリティ
  • 大規模なコミュニティ
  • Lucene開発者が作成
  • 豊富なドキュメント
  • 多数あり 利用可能なオープンソースライブラリ(Djangoを含む)

私たちはプロジェクトでこの検索エンジンを使用しており、非常に満足しています。

22
vooD

SearchTools-Aviは、「MySQLテキスト検索では、3文字以下の単語のインデックスも作成しません」と述べました。

参考までに、少なくとも MySQL 5.0であるため、MySQLフルテキストの最小語長は調整可能です。簡単な手順については、Googleの「mysql fulltext min length」。

とはいえ、MySQLのフルテキストには制限があります。1つは、100万件程度のレコードに達すると更新が遅くなる、...

10
BJ.

リストに mnoGoSearch を追加します。 Googleとして機能する非常に高性能で柔軟なソリューション:インデクサーは複数のサイトからデータを取得します。基本的な基準を使用するか、独自のフックを発明して最高の検索品質を実現できます。また、データベースから直接データを取得することもできます。

このソリューションは現在あまり知られていませんが、最大のニーズに応えます。コンパイルしてインストールするか、スタンドアロンサーバー、またはプリンシパルサーバーでさえ、Solrほどリソースを必要としません。Cで記述されており、小さなサーバーでも完全に実行できます。

最初は自分でコンパイルする必要があるため、ある程度の知識が必要です。 Debian用の小さな script を作成しました。調整は大歓迎です。

Djangoフレームワークを使用しているので、中間でPHPクライアントを使用するか、Pythonで解決策を見つけることができます some記事

そして、もちろんmnoGoSearchはオープンソース、GNU GPLです。

2
Fedir RYKHTIK