Azure AI Search でインデックスをドロップしてリビルドする

[アーティクル]
01/12/2024

このアーティクルでは、Azure AI Search インデックスをドロップしてリビルドする方法について説明します。再構築が必要な状況について説明し、進行中のクエリ要求に対する再構築の影響を軽減するための推奨事項を提供します。再構築が頻繁に必要となる場合は、インデックスの別名を使用して、アプリケーションが指しているインデックスを簡単に入れ替えられるようにすることをお勧めします。

アクティブな開発中は、インデックスデザインを反復処理するときにインデックスを削除して再構築するのが一般的です。ほとんどの開発者は、小規模の代表的なデータサンプルを使用して、インデックスの再作成が迅速に行われるようにします。

再構築を必要とする変更

次の表に、インデックスのドロップと再構築を必要とする変更の一覧を示します。

アクション	説明
フィールドの削除	フィールドのすべてのトレースを物理的に削除するには、インデックスを再構築する必要があります。実務上すぐに再構築しない場合は、古いフィールドからアクセスをリダイレクトするようにアプリケーションコードを変更することも、searchFields と select クエリパラメータを使用して、検索されて返されるフィールドを選択することもできます。物理的には、そのフィールドを無視するスキーマを適用すると、次に再構築が行われるまでフィールドの定義と内容はインデックスに維持されます。
フィールド定義を変更する	フィールドの名前、データ型、または特定のインデックス属性 (検索可能、フィルター可能、ソート可能、ファセット可能) を変更する場合は、完全な再構築が必要です。
アナライザーをフィールドに割り当てる	アナライザーはインデックスで定義され、フィールドに割り当てられ、インデックス作成中に呼び出されて、トークンがどのように作成されるかを通知します。新しいアナライザー定義はいつでもインデックスに追加できますが、アナライザーを "割り当てる" ことができるのはフィールドの作成時のみです。これは analyzer と indexAnalyzer の両方のプロパティに当てはまります。 searchAnalyzer プロパティは例外です (このプロパティは既存のフィールドに割り当てることができます)。
インデックス内のアナライザー定義を更新または削除する	インデックス全体を再構築しない限り、インデックス内にある既存のアナライザー構成 (アナライザー、トークナイザー、トークンフィルター、または文字フィルター) を削除または変更することはできません。
サジェスタにフィールドを追加する	フィールドが既に存在していて、それを Suggesters コンストラクトに追加する場合は、インデックスを再構築します。
階層を切り替える	インプレースアップグレードはサポートされていません。容量を増やす必要がある場合は、新しいサービスを作成し、インデックスを最初から再構築します。このプロセスを自動化するために、index-backup-restoreのサンプルコードを使用します、この Azure AI Search .NET サンプルリポジトリ内にあります。このアプリでは、一連の JSON ファイルにインデックスをバックアップし、指定した検索サービスでインデックスを再作成します。

再構築が必要のない変更

他の変更の多くは、既存の物理構造に影響を与えずに行うことができます。具体的には、次の変更ではインデックスの再構築は必要ありません。これらの変更については、既存のインデックス定義を更新することができます。

新しいフィールドの追加
既存のフィールドに retrievable 属性を設定する
既存の indexAnalyzer があるフィールドの searchAnalyzer を更新する
新しいアナライザー定義をインデックスに追加する (新しいフィールドに適用可能)
スコアリングプロファイルを追加、更新、削除する
CORS の設定を追加、更新、削除する
synonymMap を追加、更新、削除する
セマンティック構成を追加、更新、削除する

新しいフィールドを追加すると、既存のインデックス付きドキュメントの新しいフィールドには null 値が設定されます。今後のデータ更新では、外部ソースデータの値によって、Azure AI Search によって追加された null が置き換えられます。インデックスの内容の更新に関して詳しくは、ドキュメントの追加、更新、削除に関するページをご覧ください。

インデックスを再構築する方法

開発中、インデックススキーマが頻繁に変更されます。インデックススキーマは、小規模の代表的データセットで簡単に削除、再作成、再読み込みできるインデックスを作成することで計画できます。

既に運用環境で使用されているアプリケーションの場合は、クエリのダウンタイムを回避するため、既存のインデックスと並行して実行する新しいインデックスを作成することをお勧めします。アプリケーションコードによって新しいインデックスにリダイレクトされます。

領域を確認します。検索サービスはインデックスの最大数の影響を受けサービスレベルによって異なります。 2 番目のインデックスのための領域があることを確認します。
再構築が必要かどうかが判断されます。フィールドを追加するだけの場合や、フィールドに関係のないインデックスの一部を変更する場合は、定義を削除、再作成、または完全に再読み込みしなくても、定義を更新するだけで済む場合があります。
将来参照する場合に備え、インデックス定義を取得します。
新しいインデックスと古いインデックスをサイドバイサイドで実行していない場合は、既存のインデックスを削除します。

そのインデックスを対象とするすべてのクエリがすぐに削除されます。インデックスの削除は元に戻すことができません。フィールドコレクションやその他の構造の物理ストレージが破壊されます。削除の影響についてよく考え、それから削除してください。
変更 (修正) 後の定義が要求本文に含まれる、改訂版インデックスを作成します。
外部ソースからドキュメントでインデックスを読み込みます。

インデックスを作成すると、インデックススキーマのフィールドごとに物理ストレージが割り当てられ、各検索可能フィールドに対して逆インデックスが作成されます。検索できないフィールドは、フィルターまたは式で使用できますが、逆インデックスを持たないため、フルテキスト検索やあいまい検索はできません。インデックスの再構築では、これらの逆インデックスが削除されて、指定したインデックススキーマに基づいて再作成されます。

インデックスを読み込むと、各ドキュメントからの一意のトークン化されたすべての単語と、対応するドキュメント ID へのマップで、各フィールドの逆インデックスが設定されます。たとえば、ホテルのデータセットのインデックスを作成すると、市フィールドに対して作成される逆インデックスには、シアトルやポートランドなどの語句が含まれる可能性があります。市フィールドにシアトルまたはポートランドが含まれるドキュメントでは、語句と共にドキュメント ID がリストされます。追加、更新、削除操作では、語句とドキュメント ID のリストが相応に更新されます。

ワークロードの分散

インデックス作成はバックグラウンドでは実行されませんが、インデックス作成ジョブと進行中のクエリのバランスは、検索サービスによって調整されます。インデックス作成中、クエリがタイムリーに完了するようポータルでクエリ要求を監視できます。

インデックス作成のワークロードにより、許容できないレベルのクエリ待機時間が発生する場合は、パフォーマンス分析を実施し、潜在的な軽減策についてこれらのパフォーマンスに関するヒントを確認してください。

更新プログラムの確認

最初のドキュメントが読み込まれたらすぐに、インデックスのクエリを始めることができます。ドキュメントの ID がわかっている場合、Lookup Document REST API では特定のドキュメントが返されます。さらに範囲の広いテストでは、インデックスが完全に読み込まれるまで待ってから、クエリを使用して表示されるはずのコンテキストを確認する必要があります。

Search エクスプローラーまたは REST クライアントを使用して、更新されたコンテンツをチェックできます。

フィールドを追加したり名前変更したりした場合は、$select を使用してこのフィールドを返します。search=*&$select=document-id,my-new-field,some-old-field&$count=true