3

Rails 3 と Sunspot solr 3.5 を使用しています。私のアプリケーションは、Solr を使用してユーザー生成コンテンツのインデックスを作成し、他のユーザーが検索できるようにします。目標は、ユーザーがこのデータをアップロードしてからできるだけ早く検索できるようにすることです。これがリアルタイム検索に該当するかどうかはわかりません。

私のアプリケーションには 2 つのモデルがあります

  1. 投稿
  2. PostItems

ユーザーが post_item レコードで提供される特定の説明に基づいて検索すると、対応する投稿オブジェクトが検索で使用可能になるように、投稿アイテムのデータを含めることで投稿にインデックスを付けます。

ユーザーは頻繁に post_item を更新するため、新しい post_item が追加されるたびに、検索中に新しい post_item を使用できるように、対応する投稿オブジェクトのインデックスを再作成する必要があります。

したがって、現時点では、新しい post_item オブジェクトを受け取るたびに実行します


 post_item.post.solr_index! #

このドキュメントによると、インデックスとコミットを即座に更新します。これは機能しますが、これはこのシナリオでインデックス作成を処理する正しい方法ですか? ここで、検索中に index を呼び出すと solr が壊れる可能性があることを読みました。また、頻繁に手動でインデックスを呼び出すこともできません。

これを行う正しい方法に関する提案。ElasticSearch に切り替える以外の選択肢はありますか

4

2 に答える 2

1

始めたばかりで、Solr と ElasticSearch のどちらかを選択する余裕がある場合は、go with ElasticSearch.

私たちは本番環境で Solr を使用していますが、インデックスと検索ボリュームが増加するにつれて、多くの奇妙な問題に遭遇しました。結論として、Solr は膨大なドキュメント (word/pdf コンテンツ) のインデックス作成用に構築/最適化されていますが、インデックスは 1 日 1 回または誰も検索していない数日に 1 回更新されます。

ドキュメントが小さく、数が少ない（数百万）更新がランダムで継続的であり、検索がある程度リアルタイムである必要がある（5〜10秒の遅延は問題ありません）消費者Railsアプリケーションにとって、これは間違った選択でした。

サーバーを調整するために適用したいくつかのトリック。

removed all commits (i.e., !) from rails code, 
use Solr auto-commit every 5/20 seconds, 
have master/slave configuration, 
run index optimization(on Master) every 1 hour 
and more.

コミットがトリガーされると、スレーブの CPU 使用率が依然として高くなります。その結果、一部の検索に時間がかかります (> 60 秒)。

sunspot_index_queue gemまた、バッチ インデックス作成が高 CPU の問題を解決できるかどうかも疑問です。

于 2012-09-02T19:20:34.127 に答える