Solrがoptimizeコマンドによって明示的に、またはmergeFactorによってLuceneによって暗黙的に最適化を実行する場合、リーダーはブロックされないことを私は知っています。つまり、サーバーは引き続き検索できます
アップデートも可能ですか?私のアプリケーションの他のスレッドはドキュメントの更新をsolrに送信でき、場合によってはコミットも送信できますか?それらの更新はインデックスに渡されますか、それともブロックされますか?
Solrがoptimizeコマンドによって明示的に、またはmergeFactorによってLuceneによって暗黙的に最適化を実行する場合、リーダーはブロックされないことを私は知っています。つまり、サーバーは引き続き検索できます
アップデートも可能ですか?私のアプリケーションの他のスレッドはドキュメントの更新をsolrに送信でき、場合によってはコミットも送信できますか?それらの更新はインデックスに渡されますか、それともブロックされますか?
ただし、古い質問がここで役立つ場合があります。
solrのoptimizeコマンドは、IndexWriterのforceMerge()メソッドの呼び出しです。このメソッドは、IndexWriterインスタンス自体をロックします。ただし、重要なのは、ドキュメントを追加するためにIWインスタンスをロックする必要はなく、commitLockやfullFlushLockも必要ないということです。さらに、forceMerge()を使用しても、マージプロセスを取得し、まったく別のスレッドで実行するのはConcurrentMergeSchedulerです。
通常、マージプロセス(forceMergeではなく、とにかく推奨されません)は、マージ情報の準備中、マージに使用するセグメント、新しいマージされたセグメント名などを知る必要がある場合にのみ、IndexWriterインスタンスをロックする必要があります。この情報があり、マージは同時に行われます。
したがって、はい、最適化が進行中であってもドキュメントを追加し続けることができます-それらはIndexWriterの次のcommit /optimizeまたはclose()までRAMにバッファリングされます。
そうは言っても、異なるセグメントへの同時コミットはできないことを付け加えるかもしれません。つまり、Luceneは一度に1つのコミットしか実行しません。ドキュメントを追加しても、それらはどのセグメントにもフラッシュされません。ドキュメントをバッファに入れるだけです。
答えは「はい」です。サーバーは検索要求に応答しますが、commit
コマンドを送信するまで、更新されたドキュメントは検索結果に表示されません。commit
クライアント/スレッドがサーバーにコマンドを発行するたびに、更新されたドキュメントがスタックされてコミットされます。複数のクライアント/スレッドを発行updates
していて、commits
それらが相互にブロックしない場合、commit
コマンドが完了するとすぐに更新が表示されます。