再インデックス
Solr の構成に変更を加える場合、特にスキーマの変更では、データを再インデックスする必要があるいくつかの種類があります。
これらの変更には、フィールドまたはフィールドタイプのプロパティの編集、フィールドまたはコピーフィールドルールの追加、Solr のアップグレード、および特定のシステム構成プロパティの変更が含まれます。
再インデックスに失敗すると、Solr や、ユーザーが探しているものを見つけるのに、明白な影響と微妙な影響の両方がある可能性があることに注意することが重要です。
このコンテキストでの「再インデックス」とは、*最初に既存のインデックスを削除し、システムオブレコードからコーパス全体を取り込むために使用したプロセスを繰り返す*ことを意味します。Solr ユーザーは、必要に応じてインデックスを再作成できるように、一貫性のある反復可能なインデックス作成プロセスを持つことを強くお勧めします。
|
すべてのドキュメントと Lucene セグメントが削除されたことを最初に確認せずにコーパス内のすべてのドキュメントを再取り込みすることは、十分ではありません。セクション再インデックス戦略を参照してください。 |
再インデックスはメジャーアップグレード中に行うことが推奨されるため、このセクションでは、どのような種類の構成変更が再インデックスをトリガーする必要があるかに加えて、再インデックス戦略についても説明します。
再インデックスが必要な変更
スキーマの変更
ごくわずかな例外を除き、コレクションのスキーマを変更するには再インデックスが必要です。これは、利用可能なオプションの多くがインデックス作成プロセス中にのみ適用されるためです。Solr はデータを再インデックスすることなく、目的の変更を実装する方法がありません。
再インデックスが常に必要な一般的な理由を理解するには、Solr のスキーマと基になる Lucene インデックスの関係を理解すると役立ちます。Lucene はスキーマを使用しません。スキーマは Solr のみの概念です。Solr のスキーマを変更しても、Lucene インデックスは一切変更されません。
これは、Solr のスキーマを変更するだけでインデックスに反映できない多くの種類のスキーマ変更があることを意味します。これは、スキーマが使用されるほとんどのデータベースモデルとは異なります。インデックス作成時、Solr のスキーマは、送信されるデータを Lucene がどのように解釈するかを指示することで、ドキュメントをインデックス作成するためのルールブックのように機能します。ドキュメントが Lucene に入ると、Solr のスキーマは基になるデータ構造を制御できなくなります。
さらに、スキーマの version プロパティを変更することは、フィールドタイプのプロパティを変更することと同等です。このタイプの変更は、通常、メジャーアップグレード中またはメジャーアップグレードが原因でのみ行われます。
フィールドとフィールドタイプのプロパティの変更
フィールドの追加、削除、またはフィールドやフィールド型の定義の変更によってスキーマを変更する場合、通常、これらの変更によってドキュメントの検索方法を変更することを意図しています。これらの変更の完全な効果は、すべてのドキュメントが再インデックスされるまで、コーパス全体に反映されません。
フィールド型プロパティで説明されているいずれかのフィールド/フィールド型プロパティへの変更は、変更がすべてのドキュメントに反映されるようにするために、再インデックスが必要です。
|
再インデックスせずにインデックス作成に影響を与えるフィールドプロパティを変更することは推奨されません。これは、結果を十分に理解した上で試みる必要があります。ユーザーへの悪影響はすぐには明らかにならない可能性があります。 |
フィールド分析の変更
特定のフィールドレベルのプロパティに加えて、分析チェーンもフィールド型で構成され、インデックス時とクエリ時に適用されます。
フィールドのクエリとインデックス作成イベントに対して個別の分析チェーンが定義されており、クエリ時の分析チェーンのみを変更する場合、再インデックスは不要です。
インデックス時の分析チェーンへの変更は、ほとんどの場合、再インデックスが必要です。
Solrconfig の変更
solrconfig.xml への変更で、データの取り込み方法が変更され、再インデックスが必要になるかどうかを特定するのは、それほど簡単ではありません。一般的なルールは、「インデックスに格納される内容を変更するものは、再インデックスが必要」ということです。以下に、いくつかの既知の例を示します。
solrconfig.xml のパラメーター luceneMatchVersion は、Solr と Lucene の互換性を制御します。このパラメーターは、背後にある分析のルールを変更する可能性があるため、変更する場合は常に再インデックスすることをお勧めします。通常、これはメジャーアップグレードと組み合わせてのみ変更されます。
Solr の 更新リクエストプロセッサーを変更する場合、通常は更新リクエスト（ドキュメント）がどのように処理（インデックス作成）されるかについて何かを変更したいからです。この場合、スキーマを変更した場合と同様に、変更を実装するためにドキュメントを再インデックスすることをお勧めします。
同様に、solrconfig.xml の codecFactory パラメーターを変更する場合も、意図しない動作を避けるために、ドキュメントを再インデックスすることを計画することを強くお勧めします。
アップグレード
メジャーバージョン間（たとえば、7.x リリースから 8.x リリース）にアップグレードする場合、常にデータを再インデックスすることがベストプラクティスです。これは、デフォルトのフィールド型定義や基盤となるコードで微妙な変更が発生する可能性があるためです。
Lucene は、1 つのメジャーバージョンとの下位互換性を保証するために懸命に取り組んでいます。したがって、Solr 8x は Solr 7x で作成されたインデックスで機能します。ただし、この保証は Solr X-2 (この例では Solr 6x) には適用されないため、Solr X-1 から Solr X に移行する場合は、引き続き完全に再インデックスすることをお勧めします。
| マイナーリリースから別のマイナーリリース（たとえば、7.x からそれ以降の 7.x リリース）へのアップグレードの一部としてスキーマを変更していない場合は、ドキュメントの再インデックスをスキップできることがよくあります。ただし、メジャーリリースにアップグレードする場合は、ドキュメントを再インデックスすることを計画する必要があります。 |
| X-1 より古い Solr バージョンで作成されたインデックスをアップグレードする場合は、常にコーパスを再インデックスする必要があります。たとえば、Solr 8x にアップグレードする場合、Solr 6x で使用されたインデックスは削除し、以下に示すように再取り込みする必要があります。最初のドキュメントを取り込むために使用された Lucene のバージョンを特定するマーカーが書き込まれます。そのマーカーは、インデックスが完全に削除されない限り、インデックス内に永久に保持されます。Lucene が X-1 メジャーバージョンより古いマーカーを見つけた場合、インデックスを開くことを拒否します。 |
再インデックス戦略
再インデックスを実行するために利用できるアプローチがいくつかあります。
以下に示す戦略は、Lucene インデックスが完全に削除され、変更に対応するために再作成できることを保証します。これにより、古いデータが残ったままの Lucene セグメントなしで Lucene インデックスを再作成できます。
|
Lucene インデックスは、高速検索用に設計された損失のある抽象化です。ドキュメントがインデックスに追加されると、元のデータが使用可能であると想定することはできません。したがって、Lucene がスキーマへの変更を反映するように既存のドキュメントを「修正」することはできず、再度インデックスを作成する必要があります。 すべてのドキュメントを再取り込みする場合、最初にコーパス全体を削除せずに、すべてのドキュメントを正しく再取り込みすることは、コーディングおよび保守が難しく、エラーが発生しやすくなる技術的な理由が多数あります。 したがって、すべてのドキュメントに対して抽象化が新しいスキーマを忠実に反映することを保証するために、すべてのドキュメントを再取り込みする必要があるため、古い Lucene セグメントがないことを確認した後、すべてのドキュメントを削除するか、新しいコレクションに再インデックスすることをお勧めします。 |
すべてのドキュメントを削除する
最良のアプローチは、最初にインデックスからすべてを削除し、次にデータを再度インデックスすることです。次のような「delete-by-query」を使用して、すべてのドキュメントを削除できます。
curl -X POST -H 'Content-Type: application/json' --data-binary '{"delete":{"query":"*:*" }}' http://localhost:8983/solr/my_collection/updateLucene インデックスセグメントも削除されることを保証するために、すべてのドキュメントが削除されたことを確認することが重要です。
インデックスにセグメントがないことを確認するには、data/index ディレクトリを見て、セグメントファイルがないことを確認します。データディレクトリはカスタマイズできるため、インデックスファイルの場所については、dataDir パラメーターを使用したインデックスデータの場所の指定セクションを参照してください。
クラスターのすべてのノード上のすべてのシャードとすべてのレプリカでインデックスが削除されていることを確認する必要があります。ドキュメントの数をクエリするだけでは不十分です。ドキュメントがなくてもインデックスセグメントが残っている可能性があるためです。
インデックスがクリアされたら、元のインデックスプロセスを再実行して再インデックスを開始できます。
| このアプローチの代替手段として、更新されたスキーマを使用してコレクションを削除して再作成し、再インデックスプロセス中にコレクションをオフラインにしてもよい場合は、再インデックスできます。 |
別のコレクションへのインデックス
別のアプローチは、新しいコレクションにインデックスを作成し、Solr の コレクションエイリアス機能を使用して、ダウンタイムなしでアプリケーションを新しいコレクションにシームレスにポイントすることです。
このオプションは、SolrCloud モードで実行されている Solr インストールでのみ利用可能です。
このアプローチでは、変更を使用する新しいコレクションにドキュメントをインデックス作成し、インデックス作成とテストが完了したら、フロントエンドを新しいコレクションに向けるエイリアスを作成します。その時点から、新しいクエリと更新は新しいコレクションにシームレスにルーティングされます。
エイリアスが配置され、古いデータが不要になったことが確認できたら、Collections API の DELETE コマンドを使用して古いコレクションを削除できます。
| このオプションの利点の 1 つは、テストで発見できなかった問題を発見した場合に、古いコレクションに切り替えることができることです。もちろん、このオプションでは、古いコレクションを削除できるようになるまで、より多くのリソースが必要になる可能性があります。 |