5

現在実行中のインデックスを下げることなく、増え続けるドキュメントのコーパス (現在は数千万件、1 年以内に数億件) を Solr で体系的に再インデックスする方法について、いくつかの推奨事項を探しています。次の理由により、定期的にインデックスを再作成する必要があります。

  • 追加のスキーマ フィールドを必要とする既存のコーパスの検索に関する新機能が導入されましたが、これは常に事前に予測することはできません。
  • コーパスは、複数のシャードにわたって索引付けされています。一定のしきい値を超えて成長すると、さらに多くのシャードを作成し、それらすべてに均等にドキュメントのバランスを再調整する必要があります (SolrCloud はまだサポートしていないようです)。

現在のインデックスは非常に頻繁に更新や追加が行われるため、数分以内に検索できるようにする必要があります。したがって、コーパスがバッチ オフラインで再インデックス化されるアプローチは、バッチが終了するまでに新しいドキュメントが利用可能になるため、実際には機能しません。

現時点で検討しているアプローチは次のとおりです。

  • シャードの新しいクラスターを作成し、古いクラスターがまだ検索に使用できる間に、そこでバッチ再インデックスを作成します。再インデックスされたバッチの一部ではない新しいドキュメントは、古いクラスターと新しいクラスターの両方に送信されます。切り替える準備ができたら、ロード バランサーを新しいクラスターに向けます。
  • CoreAdmin を使用します。シャードごとに新しいコアを生成し、インデックスを再作成したバッチを新しいコアに送信します。再インデックスされたバッチの一部ではない新しいドキュメントは、古いコアと新しいコアの両方に送信されます。切り替える準備ができたら、CoreAdmin を使用して動的にコアを交換します。

これらのアプローチのいずれかまたはすべてについて、確認するか穴を開けていただけると幸いです。どちらが適切ですか？それとも完全にオフですか？前もって感謝します。

4

1 に答える 1

2

これは皆さんには当てはまらないかもしれませんが、この問題に対する私のアプローチを提供します。

Solr のセットアップは現在、シングル コアです。将来的にさらにコアを追加する予定ですが、圧倒的多数のデータは単一のコアに書き込まれます。

これを念頭に置いて、シャーディングは実際には私たちには当てはまりませんでした。私は分散検索を調べました - データを分割し、異なるサーバーで実行するさまざまなスライスを持っています。これは、私には、物事を複雑にしすぎているように思えました。バックアップ/復元がより困難になり、分散検索を実行するときに特定の機能を失うことになります。

私たちが最終的に採用したアプローチは、非常に単純なクラスター化されたマスター/スレーブのセットアップでした。

各クラスターは、マスター データベースと、負荷分散された 2 つの solr スレーブで構成されます。新しいデータはすべてマスター データベースに書き込まれ、スレーブは新しいデータを 5 分ごとに同期するように構成されます。通常の状況では、これは非常に優れた設定です。再インデックス操作はマスターで発生し、これが発生している間もスレーブから読み取ることができます。

大規模な再インデックス操作が発生している場合、ロード バランサーから 1 つのスレーブを削除し、もう 1 つのスレーブのポーリングをオフにします。そのため、Solr データベースに直面している顧客は現在マスターと同期していませんが、もう一方は更新されています。インデックスの再作成が完了し、オフラインのスレーブ データベースが同期されたら、それをロード バランサーに追加し直し、他のスレーブ データベースをロード バランサーから削除して、マスターと同期するように再構成します。

これまでのところ、これは非常にうまく機能しています。現在、データベースには約 500 万のドキュメントがあり、この数は複数のクラスター間でさらに大きくなります。

お役に立てれば！

于 2011-05-22T17:06:55.637 に答える