Ruby on Rails アプリケーションに検索エンジンを組み込むためのプラグイン オプションがいくつかあります。これらのうちどれが最高ですか?
19 に答える
Thinking Sphinx には、インデックスを作成するフィールドとモデルを定義するためのより簡潔な構文があります。
UltraSphinx と Thinking Sphinx (最近) の両方に、オブジェクトの地理的近接性を考慮した超クールな機能があります。
UltraSphinx には、モデルのロード方法に関する厄介な問題があります (Rails スタック全体をロードしないため、明示的なrequire
ステートメントを追加することによって処理される、奇妙で診断が難しいエラーが発生する可能性があります)。
新しいプロジェクトでは Thinking Sphinx を使用し、ジオ コンテンツを使用するプロジェクトでは UltraSphinx を使用しています。
この質問は以前にここで尋ねられ、より詳細な回答がありました。
私は今まさにこのプロセスを行っているので、実際の経験はありませんが、すべてのオプションを調査するのに何時間も費やしました. これまでに学んだことは次のとおりです。
- *Sphinx - 速度と機能で定評がありますが、Sphinx には整数キーが必要で、私のモデルは GUID を使用しています。ThinkingSphinx は最近 GeoSpatial のサポートを発表しました
- Acts_As_Solr - 大量のサイトを持つ友人が推奨する; 元の作成者は作業を中止しており、ドキュメントを見つけるのは困難です。Java サーブレットが必要です
- Acts_As_Ferret - 使いやすそうに見えますが、不安定だと批判する人がたくさんいます
- 情報が限られている他の 2 つは、Acts_As_Indexed と Acts_As_Searchable です。
それらすべての長所と短所を文書化しようとするスプレッドシートがあります。誰かがそれを見て、私がそれを修正するのを手伝ってくれることに興味があるなら、私に連絡してください. 正確なことがわかったら、どこかに投稿します。
通常の主キーがある場合は、UltraSphinx または Thinking Sphinx を試すことをお勧めします。優れたドキュメント、機能セット、およびプロジェクトがどれだけ活発であるかに基づいて、Acts_As_Xapian を試してみます。
私の友人の 1 人が使用している確かなオプションは、元の Java ベースの Lucene を使用する検索エンジンであるSolrです。Rails で使用するには、もちろん act_as プラグインの act_as_solr があります。
彼は最近、Montreal on Railsでこのコンボを発表し、彼のブログでacts_as_solr の使用方法の素晴らしい完全な概要を提供しています。
フランス語のアクセントも非常によくサポートしているようです。
クライアント プロジェクトで Ferret/acts_as_ferret コンボ (従来の決定) のみを使用しました。最初に他のオプションを検討することを強くお勧めします。
aaf は非常に壊れやすく、構成を間違えたり、何らかの理由で aaf にバグが発生した場合に、Rails アプリが急停止する可能性があります。
このような場合、単純に検索機能を無効にする代わりに、インデックス付きモデルに触れるコントローラー アクションは完全に失敗し、例外が発生します。うーん、どれが悪いですか?
私のような共有ホスティングサービス(Bluehost)を使用している場合、オプションはプロバイダーが提供するものに制限される可能性があります。私の場合、LuceneやSolrなどの別のサーバーを起動して実行し続けるための適切で信頼性の高い方法を見つけることができませんでした。
したがって、私はXapianを使用しましたが、それは私にとってうまく機能しています。私が調査したRailsには、acts_as_xapianとxapian_fuの2つのプラグインがあります。最初のものはあなたをすぐに動かすでしょう、しかしそれはもう維持されていないようです。xapian_fuの使用を開始しました。
私はacts_as_ferretを使用しています。構成は簡単で、一般的に高速です。組み込みのアクティブ レコード検索機能は非常に便利です。検索で一致するレコードが見つかった後、任意の条件を適用したり、他のモデルに参加したりできます。
Sphinx とは異なり、新しいデータを追加するときにすべてのレコードを再インデックス化する必要はありません。新しいレコードを ferret db に挿入する after_save および after_update フックがあります。これは私にとって大きなセールスポイントの1つでした。
データを大量にインデックス化する必要がある場合、ferret は act_as_sphinx よりも明らかに遅くなります (3 倍)。最終的に、スフィンクスと同じくらい高速に動作するモデルを再インデックス化する独自の方法を作成しました。基本的に、レコードごとに移動して新しいインデックスを作成するのではなく、DB からすべてのデータをプリロードします。
フェレットのドキュメントは基本的なことには適していますが、より複雑な検索、並べ替え、dRb サーバーを使用してリモート インデックスをホストするようになると、少しまばらになります。そうは言っても、私は sphinx の経験が限られていますが、acts_as_sphinx よりもはるかに成熟した製品だと感じています。
私はacts_as_xapianプラグインを使用しています。私はこのチュートリアルに従いました:
http://locomotivation.com/2008/07/23/simple-ruby-on-rails-full-text-search-using-xapian
非常にうまく機能します。
スフィンクスを考えることは、見捨てられたように見えるウルトラスフィンクスよりも優れた代替手段ですが、一般的に、Xapianはスフィンクスよりも強力なエンジンを備えており、リアルタイム検索の実装が簡単です。
私は驚くほどうまくいった別のオプションを使用しています。私は jruby を使用して、lucene と直接話しています。
過去にacts_as_solrを使用したことがあり、いくつかの問題に遭遇しました。主に、AR 保存ごとに同期呼び出しを行います。これはそれほど悪くはありませんが、私の状況では、保存によって solr への多くの同期呼び出しが発生することがあり、mongrel が許可するよりも時間がかかり、mongrel タイムアウト例外 (またはそのようなもの) が発生することがありました。
私は Thinking Sphinx を使用しましたが、かなり良いように思えますが、すべてのオプションを評価する時間がありませんでした。
私も完璧な解決策を探していました。最初は、問題なく機能する Thinking Sphinx を使用しました。しかし、 Herokuでwebapp をホストするつもりなので、唯一のオプションはSolrを使用することです。ただし、最大の欠点は、メインのact_as_solr gem の開発が 2008 年 5 月以降に停止しているように見えることです。Sunspotが高度な代替手段であり、最近の更新が含まれていることを発見したので、それを検討します。
Heroku が提供するもう 1 つのオプションは、 Websolrという名前の Solr ベースのホスト型インデックス サーバーを使用することです。必要な gem websolr-acts_as_solrも幸運にも非常に最新です。
使用しているデータベースによって異なります。Solr はあいまい検索のための優れたオプションを多数提供し、優れたクエリ パーサーを備えているため、Solr の使用をお勧めします。欠点は、別のプロセスを実行する必要があることです。Ferret も使用しましたが、インデックスへのマルチスレッド アクセスに関しては安定性が低いことがわかりました。MySQL と Postgres でしか動作しないため、Sphinx は試していません。
シンキング スフィンクスがおすすめです。私の意見では、これが最速のオプションです。
私は Ferret を使用しており、私の目的にはうまく機能しましたが、他のオプションは評価していません。
私が試していないオプションは、C++ ベースのXapianです。
継承されたhttp://hyperestraier.sourceforge.net/を使用しています。他のエンジンは調べていませんが、hyperestraier は必要なすべてのフックを提供します。ただし、検索インデックスの設定は複雑です。おそらくより簡単なオプションが利用可能です。