データベース全体のインデックスを時々再作成します。通常、数時間かかります。ただし、最新のものだけがフロント ページに表示されます。したがって、データベースを逆方向に再インデックス化すると、つまり最初に「id desc」の順序でレコードを再インデックス化すると、サーバーのダウンタイムを大幅に短縮できると考えています。
しかし、パフォーマンスの観点からは、これで問題ないのでしょうか? 検索時間に悪影響を与える可能性はありますか?
完全な再インデックスを行っているとのことなので、別のコアでインデックスを作成してスワップすることをお勧めします。この回答は、これを実現する方法に関するいくつかの参照を提供します。
私たちのセットアップでは、マスター/スレーブのセットアップがあり、マスターでインデックス作成が行われ、インデックスがスレーブに複製されます。スレーブは検索リクエストを処理します。これは、パフォーマンスの観点からはうまく機能します。
考慮すべきもう 1 つの点は、インデックス作成に時間がかかる理由を試してみることです。私たちの場合、DataImportHandler 内のネストされたクエリが原因であり、n+1 個の jdbc 接続を起動していることに気付きました。ビューを作成して最適化したところ、インデックス作成時間が 3 時間から 2 分未満になりました。
ダウンタイムがあるのはなぜですか?
最後にのみコミットすると、コミットを行うときに最後にのみレコードが表示されます (順序は関係ありません)。
maxDocs/maxTime セット (Solr 4+) を使用してソフトコミットを実行し、最新のレコードからインデックスを再作成している場合、それらのレコードはほとんどすぐに表示され、他のレコードは最終的に表示されます。
コミットのセマンティクスについて少し読んで、それが物事をより明確にするかどうかを確認することをお勧めします。