Azure Cognitive Search インデックスを再構築する方法How to rebuild an Azure Cognitive Search index

この記事では、Azure Cognitive Search インデックスを再構築する方法、再構築が必要な状況、および実行中のクエリ要求に対する再構築の影響を軽減するためのレコメンデーションについて説明します。This article explains how to rebuild an Azure Cognitive Search index, the circumstances under which rebuilds are required, and recommendations for mitigating the impact of rebuilds on ongoing query requests.

"再構築" とは、フィールドに基づくすべての逆インデックスなど、インデックスに関連付けられている物理的なデータ構造を削除して作成しなおすことです。A rebuild refers to dropping and recreating the physical data structures associated with an index, including all field-based inverted indexes. Azure Cognitive Search では、個々のフィールドを削除して再作成することはできません。In Azure Cognitive Search, you cannot drop and recreate individual fields. インデックスを再構築するには、すべてのフィールド ストレージを削除して、既存のインデックス スキーマまたは変更したインデックス スキーマに基づいて再作成した後、インデックスにプッシュされたデータまたは外部ソースからプルされたデータで再設定する必要があります。To rebuild an index, all field storage must be deleted, recreated based on an existing or revised index schema, and then repopulated with data pushed to the index or pulled from external sources. インデックスの再構築は開発中に行うのが一般的ですが、構造の変更 (複合型の追加、サジェスターへのフィールドの追加など) に対応するために、運用レベルのインデックスの再構築が必要になることもあります。It's common to rebuild indexes during development, but you might also need to rebuild a production-level index to accommodate structural changes, such as adding complex types or adding fields to suggesters.

インデックスをオフラインにして行われる再構築とは対照的に、"データの更新" はバックグラウンド タスクとして実行されます。In contrast with rebuilds that take an index offline, data refresh runs as a background task. クエリのワークロードに対する中断を最小限に抑えてドキュメントを追加、削除、置換できますが、通常、クエリが完了するまでの時間は長くなります。You can add, remove, and replace documents with minimal disruption to query workloads, although queries typically take longer to complete. インデックスの内容の更新に関して詳しくは、ドキュメントの追加、更新、削除に関するページをご覧ください。For more information on updating index content, see Add, Update or Delete Documents.

再構築の条件Rebuild conditions

条件Condition 説明Description
フィールド定義を変更するChange a field definition フィールドの名前、データ型、または特定のインデックス属性 (検索可能、フィルター可能、ソート可能、ファセット可能) を変更すると、完全な再構築が必要です。Revising a field name, data type, or specific index attributes (searchable, filterable, sortable, facetable) requires a full rebuild.
アナライザーをフィールドに割り当てるAssign an analyzer to a field アナライザーはインデックスで定義されてからフィールドに割り当てられます。Analyzers are defined in an index and then assigned to fields. 新しいアナライザー定義はいつでもインデックスに追加できますが、アナライザーを "割り当てる" ことができるのはフィールドの作成時のみです。You can add a new analyzer definition to an index at any time, but you can only assign an analyzer when the field is created. これは analyzerindexAnalyzer の両方のプロパティに当てはまります。This is true for both the analyzer and indexAnalyzer properties. searchAnalyzer プロパティは例外です (このプロパティは既存のフィールドに割り当てることができます)。The searchAnalyzer property is an exception (you can assign this property to an existing field).
インデックス内のアナライザー定義を更新または削除するUpdate or delete an analyzer definition in an index インデックス全体を再構築しない限り、インデックス内の既存のアナライザー構成 (アナライザー、トークナイザー、トークン フィルター、文字フィルター) を削除または変更することはできません。You cannot delete or change an existing analyzer configuration (analyzer, tokenizer, token filter, or char filter) in the index unless you rebuild the entire index.
サジェスタにフィールドを追加するAdd a field to a suggester フィールドが既に存在していて、それを Suggesters コンストラクトに追加する場合は、インデックスを再構築する必要があります。If a field already exists and you want to add it to a Suggesters construct, you must rebuild the index.
フィールドの削除Delete a field フィールドのすべてのトレースを物理的に削除するには、インデックスを再構築する必要があります。To physically remove all traces of a field, you have to rebuild the index. すぐに再構築できない場合は、"削除された" フィールドにアクセスしないようにアプリケーションのコードを変更することができます。When an immediate rebuild is not practical, you can modify application code to disable access to the "deleted" field. 物理的には、そのフィールドを無視するスキーマを適用すると、次に再構築が行われるまでフィールドの定義と内容はインデックスに維持されます。Physically, the field definition and contents remain in the index until the next rebuild, when you apply a schema that omits the field in question.
階層を切り替えるSwitch tiers より多くの容量が必要な場合、Azure portal にはインプレース アップグレードはありません。If you require more capacity, there is no in-place upgrade in the Azure portal. 新しいサービスを作成し、その新しいサービスで最初からインデックスを構築する必要があります。A new service must be created, and indexes must be built from scratch on the new service. このプロセスを自動化するには、こちらの Azure Cognitive Search .NET サンプル リポジトリにある index-backup-restore サンプル コードを使用します。To help automate this process, you can use the index-backup-restore sample code in this Azure Cognitive Search .NET sample repo. このアプリは、一連の JSON ファイルにインデックスをバックアップし、指定した検索サービスでインデックスを再作成します。This app will backup your index to a series of JSON files, and then recreate the index in a search service you specify.

これら以外の変更は、既存の物理構造に影響を与えずに行うことができます。Any other modification can be made without impacting existing physical structures. 具体的には、以下の変更では、インデックスの再構築を行う "必要はありません"。Specifically, the following changes do not require an index rebuild:

  • 新しいフィールドの追加Add a new field
  • 既存のフィールドに retrievable 属性を設定するSet the retrievable attribute on an existing field
  • 既存のフィールドに searchAnalyzer を設定するSet a searchAnalyzer on an existing field
  • インデックスに新しいアナライザー定義を追加するAdd a new analyzer definition in an index
  • スコアリング プロファイルを追加、更新、削除するAdd, update, or delete scoring profiles
  • CORS の設定を追加、更新、削除するAdd, update, or delete CORS settings
  • synonymMap を追加、更新、削除するAdd, update, or delete synonymMaps

新しいフィールドを追加すると、既存のインデックス付きドキュメントの新しいフィールドには null 値が設定されます。When you add a new field, existing indexed documents are given a null value for the new field. 将来のデータ更新において、Azure Cognitive Search によって追加された null 値は、外部ソース データからの値に置き換えられます。On a future data refresh, values from external source data replace the nulls added by Azure Cognitive Search. インデックスの内容の更新に関して詳しくは、ドキュメントの追加、更新、削除に関するページをご覧ください。For more information on updating index content, see Add, Update or Delete Documents.

部分的なインデックス作成Partial indexing

Azure Cognitive Search では、フィールド単位でインデックスの作成を制御することはできません (特定のフィールドの削除または再作成)。In Azure Cognitive Search, you cannot control indexing on a per-field basis, choosing to delete or recreate specific fields. 同様に、条件に基づいてドキュメントのインデックスを作成するための組み込みメカニズムはありません。Similarly, there is no built-in mechanism for indexing documents based on criteria. 条件に基づいてインデックスを作成する必要がある場合は、カスタム コードで対応する必要があります。Any requirements you have for criteria-driven indexing have to be met through custom code.

一方、インデックスでの "ドキュメントの更新" は簡単に行うことができます。What you can do easily, however, is refresh documents in an index. 多くの検索ソリューションでは、外部ソースのデータは揮発性であり、ソース データと検索インデックスを同期するのが一般的な方法です。For many search solutions, external source data is volatile, and synchronization between source data and a search index is a common practice. コードでは、ドキュメントの追加、更新、削除操作または .NET でそれに相当する機能を呼び出して、インデックスの内容を更新するか、新しいフィールドの値を追加します。In code, call the Add, Update or Delete Documents operation or the .NET equivalent to update index content, or to add values for a new field.

インデクサーでの部分的なインデックス作成Partial indexing with indexers

インデクサーを使用すると、データ更新タスクが簡単になります。Indexers simplify the data refresh task. インデクサーでは、外部データ ソースの 1 つのテーブルまたはビューのインデックスだけを作成できます。An indexer can only index one table or view in the external data source. 複数のテーブルのインデックスを作成する最も簡単な方法は、テーブルを結合してインデックス作成対象の列を投影するビューを作成することです。To index multiple tables, the simplest approach is to create a view that joins tables and projects the columns you want to index.

外部データ ソースをクロールするインデクサーを使用するときは、ソース データ内の "高基準" 列をチェックします。When using indexers that crawl external data sources, check for a "high water mark" column in the source data. 存在する場合は、新しい内容または変更された内容を含む行だけを選択することによる増分変更の検出に、それを使用することができます。If one exists, you can use it for incremental change detection by picking up just those rows containing new or revised content. Azure Blob Storageでは、lastModified フィールドを使用します。For Azure Blob storage, a lastModified field is used. Azure Table Storage では、timestamp が同じ役割を果たします。On Azure Table storage, timestamp serves the same purpose. 同様に、Azure SQL Database インデクサーAzure Cosmos DB インデクサーの両方に行更新のフラグ付けのためのフィールドがあります。Similarly, both Azure SQL Database indexer and Azure Cosmos DB indexer have fields for flagging row updates.

インデクサーについて詳しくは、インデクサーの概要および Reset Indexer REST API に関するページをご覧ください。For more information about indexers, see Indexer overview and Reset Indexer REST API.

インデックスを再構築する方法How to rebuild an index

インデックス スキーマが不安定な状態にある場合は、開発中に、頻繁に完全な再構築を実行することを計画してください。Plan on frequent, full rebuilds during active development, when index schemas are in a state of flux. 既に運用環境で使用されているアプリケーションの場合は、クエリのダウンタイムを回避するため、既存のインデックスと並行して実行する新しいインデックスを作成することをお勧めします。For applications already in production, we recommend creating a new index that runs side by side an existing index to avoid query downtime.

インデックスを更新するためには、サービスレベルでの読み取り/書き込みアクセス許可が必要です。Read-write permissions at the service-level are required for index updates.

ポータルでインデックスを再構築することはできません。You cannot rebuild an index in the portal. プログラムでは、インデックスの更新 REST API または同等の .NET API を呼び出して、完全な再構築を行うことができます。Programmatically, you can call Update Index REST API or equivalent .NET APIs for a full rebuild. インデックスの更新要求はインデックスの作成 REST API と同じですが、コンテキストが異なります。An update index request is identical to Create Index REST API, but has a different context.

次のワークフローは REST API 寄りですが、.NET SDK にも同様に適用されます。The following workflow is biased towards the REST API, but applies equally to the .NET SDK.

  1. インデックス名を再利用する場合は、既存のインデックスを削除します。When reusing an index name, drop the existing index.

    そのインデックスを対象とするすべてのクエリがすぐに削除されます。Any queries targeting that index are immediately dropped. インデックスの削除は元に戻すことができず、フィールド コレクションおよびその他の構造に対する物理ストレージが破棄されます。Deleting an index is irreversible, destroying physical storage for the fields collection and other constructs. 削除する前に、インデックスを削除したときの影響が明確になっていることを確認します。Make sure you are clear on the implications of deleting an index before you drop it.

  2. サービス エンドポイント、API キー、および管理者キーを使用してインデックスの更新要求を作成します。Formulate an Update Index request with your service endpoint, API-key, and an admin key. 書き込み操作には管理者キーが必要です。An admin key is required for write operations.

  3. 要求の本文には、変更または修正されたフィールド定義を含むインデックス スキーマを指定します。In the body of the request, provide an index schema with the changed or modified field definitions. 要求の本文には、インデックス スキーマと共に、スコアリング プロファイル、アナライザー、suggester、CORS オプションのための構造が含まれます。The request body contains the index schema, as well as constructs for scoring profiles, analyzers, suggesters, and CORS options. スキーマの要件については、インデックスの作成に関するページをご覧ください。Schema requirements are documented in Create Index.

  4. インデックスの更新要求を送信して、Azure Cognitive Search でのインデックスの物理的な表現を再構築します。Send an Update Index request to rebuild the physical expression of the index on Azure Cognitive Search.

  5. 外部ソースからドキュメントでインデックスを読み込みますLoad the index with documents from an external source.

インデックスを作成すると、インデックス スキーマのフィールドごとに物理ストレージが割り当てられ、各検索可能フィールドに対して逆インデックスが作成されます。When you create the index, physical storage is allocated for each field in the index schema, with an inverted index created for each searchable field. 検索可能ではないフィールドは、フィルターまたは式で使用できますが、逆インデックスを持たないため、フルテキスト検索またはあいまい検索を実行できません。Fields that are not searchable can be used in filters or expressions, but do not have inverted indexes and are not full-text or fuzzy searchable. インデックスの再構築では、これらの逆インデックスが削除されて、指定したインデックス スキーマに基づいて再作成されます。On an index rebuild, these inverted indexes are deleted and recreated based on the index schema you provide.

インデックスを読み込むと、各ドキュメントからの一意のトークン化されたすべての単語と、対応するドキュメント ID へのマップで、各フィールドの逆インデックスが設定されます。When you load the index, each field's inverted index is populated with all of the unique, tokenized words from each document, with a map to corresponding document IDs. たとえば、ホテルのデータ セットのインデックスを作成すると、市フィールドに対して作成される逆インデックスには、シアトルやポートランドなどの語句が含まれる可能性があります。For example, when indexing a hotels data set, an inverted index created for a City field might contain terms for Seattle, Portland, and so forth. 市フィールドにシアトルまたはポートランドが含まれるドキュメントでは、語句と共にドキュメント ID がリストされます。Documents that include Seattle or Portland in the City field would have their document ID listed alongside the term. 追加、更新、削除操作では、語句とドキュメント ID のリストが相応に更新されます。On any Add, Update or Delete operation, the terms and document ID list are updated accordingly.

注意

厳格な SLA 要件がある場合は、この作業専用に新しいサービスをプロビジョニングし、運用環境のインデックスから完全に切り離して開発とインデックス作成を行うことを検討する場合があります。If you have stringent SLA requirements, you might consider provisioning a new service specifically for this work, with development and indexing occurring in full isolation from a production index. リソースが競合する可能性がないように、独立したサービスを専用のハードウェアで実行します。A separate service runs on its own hardware, eliminating any possibility of resource contention. 開発が終わったら、新しいインデックスをそのままにして、新しいエンドポイントとインデックスにクエリをリダイレクトするか、または元の Azure Cognitive Search サービス上で完成したコードを実行して変更後のインデックスを発行します。When development is complete, you would either leave the new index in place, redirecting queries to the new endpoint and index, or you would run finished code to publish a revised index on your original Azure Cognitive Search service. 現在、すぐに使用できる状態のインデックスを別のサービスに移動するためのメカニズムはありません。There is currently no mechanism for moving a ready-to-use index to another service.

ビューの更新View updates

最初のドキュメントが読み込まれたらすぐに、インデックスのクエリを始めることができます。You can begin querying an index as soon as the first document is loaded. ドキュメントの ID がわかっている場合、Lookup Document REST API では特定のドキュメントが返されます。If you know a document's ID, the Lookup Document REST API returns the specific document. さらに範囲の広いテストでは、インデックスが完全に読み込まれるまで待ってから、クエリを使用して表示されるはずのコンテキストを確認する必要があります。For broader testing, you should wait until the index is fully loaded, and then use queries to verify the context you expect to see.

関連項目See also