コンパスマッピングやブーストの適用方法が変更された場合や、何らかの理由で何かが破損した場合など、Luceneインデックスを再生成する必要がある場合があります。
私の場合、インデックスの生成には約5〜6時間かかります。その前にインデックスをクリアすると、この間隔のデータが完成しなくなります。I.e。今回検索を行うと、不完全な結果が返されます。
Luceneにバックグラウンドでインデックスを生成させる標準的な方法はありますか？たとえば、インデックスを一時ディレクトリに書き込み、（例外などなしでインデックス作成が終了した場合）既存のインデックスを新しいインデックスに置き換えますか？
もちろん、これを「手動で」実装することもできますが、そうする必要がありますか？私には一般的なユースケースのように聞こえます。
よろしくお願いいたします+ご意見ありがとうございます
ピーター:)
これを行う通常の方法は、solrのレプリケーション機能を使用することだと思います。ただし、あなたの場合、マスターとスレーブは同じマシン上にありますが、異なるディレクトリを指しているだけです。
私も同じような経験をしました。アナライザーには、時々変更される特定のパラメーターがありました。明らかにその場合は、インデックス全体を再構築する必要があります。（詳細については説明しませんが、同じ要件があったと言えば十分です！）
私はあなたがあなたの質問で提案したことをしました。「古い」、「現在」、「新しい」の3つのディレクトリがありました。ライブサイトからのクエリは常に「現在」に反していました。インデックスの再作成プロセスは次のとおりです。
プロセスがクラッシュしたときに何が起こるかを分析します。最初のステップでクラッシュした場合は、次に続行します。2番目のステップでクラッシュした場合、「新しい」ディレクトリは次回の実行で削除されます。3番目のステップは非常に高速です。ディレクトリの名前変更は高速でアトミックです。4番目のステップでのクラッシュは問題ではなく、次の実行でクリーンアップされるだけです。
注意深い観察者は、ステップ3で、現在のディレクトリの名前を変更してから新しいディレクトリを移動するまでの間にシステムがクラッシュする可能性があることに気付くでしょう。ディレクトリの名前変更が非常に速いため、これは起こりそうにありません。このシステムは数年前から生産されており、これは（まだ？）起こったことはありません。
同様の問題があります。私たちのデータはLuceneでインデックス化されていますが、元のソースはDBとコンテンツリポジトリです。
したがって、インデックスが同期しなくなった場合（またはデータ型の変更など）、インデックス内の既存のすべてのエントリを繰り返し処理し、データを再生成して、各ドキュメントが更新されるようにします。それほど複雑なことではありません。