次の方法で共有

Azure AI Search の Azure Storage のインデクサーを使用した変更検出と削除検出

  • [アーティクル]

最初の検索インデックスが作成された後、以降のインデクサー ジョブでは、新規および変更されたドキュメントのみを取得することができます。 Azure Storage から生成されたインデックス付きコンテンツに対しては、変更検出が自動的に行われます。これは、インデクサーが Azure Storage のオブジェクトとファイルに組み込まれたタイムスタンプを使用して最終更新を追跡しているためです。

変更の検出は指定されていますが、削除検出は指定されていません。 インデクサーはデータ ソースのオブジェクトの削除を追跡しません。 孤立した検索ドキュメントが含まれないようにするには "論理的な削除" 方法を実装できます。これにより、最初に検索ドキュメントを削除した後に Azure Storage での物理的な削除が行われます。

論理的な削除方法を実装するには、2 つの方法があります。

削除検出戦略は、最初のインデクサー実行から適用する必要があります。 最初の実行の前に削除ポリシーを確立しなかった場合、ポリシーが実装される前に削除されたすべてのドキュメントは、ポリシーを後でインデクサーに追加してリセットしたとしても、インデックス内に残ることになります。 これが発生してしまった場合は、新しいインデクサーを使用して新しいインデックスを作成し、最初から削除ポリシーが設定された状態にすることが推奨されます。

前提条件

  • Azure Storage インデクサー向けの Blob Storage、Table Storage、File Storage、またはData Lake Storage Gen2 を使用

  • 一貫性のあるドキュメント キーとファイル構造を使用します。 ドキュメント キーまたはディレクトリの名前やパスを変更すると (ADLS Gen2 に該当)、インデクサーが使用する内部追跡情報が中断されます。インデクサーはこの内部追跡情報を使ってインデックスが作成されたコンテンツと最後にインデックスが作成された日時を認識します。

Note

ADLS Gen2 により、ディレクトリの名前を変更できます。 ディレクトリの名前を変更しても、そのディレクトリ内の BLOB のタイムスタンプは更新されません。 その結果、インデクサーはこれらの BLOB の再インデックス作成を行いません。 ディレクトリの名前を変更した後、ディレクトリの BLOB が新しい URL を持つことから再インデックス作成を行う必要がある場合は、ディレクトリ内のすべての BLOB の LastModified タイムスタンプを更新する必要があります。これにより、インデクサーが将来の実行中に再インデックス作成の必要性を認識できるようになります。 Azure Blob Storage の仮想ディレクトリは変更できないため、この問題は発生しません。

ネイティブ BLOB の論理的な削除

この削除検出方法では、Azure AI Search で Azure Blob Storage のネイティブ BLOB の論理的な削除機能を使用して、BLOB が論理的に削除された状態に移行したかどうかを判断します。 この状態の BLOB が検出されると、この情報が検索インデクサーで使用され、対応するドキュメントがインデックスから削除されます。

ネイティブの論理的な削除の要件

  • BLOB は、Azure Blob Storage コンテナー内に存在する必要があります。 Azure AI 検索のネイティブ BLOB の論理的な削除ポリシーは、ADLS Gen2 または Azure Files 内の BLOB に対してはサポートされていません。

  • BLOB の論理的な削除を有効にします。

  • インデックス内のドキュメントのドキュメント キーは、"metadata_storage_path" などの.BLOB プロパティと BLOB メタデータのどちらかにマップされている必要があります。

  • 論理的な削除のサポートを構成するには、プレビューの REST API (2024-05-01-preview など)、または Azure portal のインデクサー データ ソース構成を使用する必要があります。

  • ストレージ アカウントで BLOB のバージョン管理を有効にしないようにする必要があります。 そのようにしないと、ネイティブの論理的な削除が設計でサポートされなくなります。

ネイティブの論理的な削除を構成する

BLOB ストレージで、要件ごとに論理的な削除を有効にする場合、保持ポリシーをインデクサー間隔スケジュールよりも大幅に高い値に設定することをお勧めします。 インデクサーの実行で問題が発生した場合、またはインデックスを作成するドキュメントの数が多い場合に、インデクサーが論理的に削除された BLOB を最終的に処理するための時間は十分にあります。 Azure AI Search インデクサーでは、論理的に削除された状態の BLOB を処理する場合にのみ、インデックスからドキュメントが削除されます。

Azure AI Search で、データ ソースに対してネイティブ BLOB の論理的な削除の検出ポリシーを設定します。 これは Azure portal から、またはプレビューの REST API (2024-05-01-preview) を使用して行うことができます。 次の手順では、Azure portal または REST API を使用して削除検出ポリシーを設定する方法について説明します。

  1. Azure portal にサインインします。

  2. Azure AI Search サービスの概要ページで、データ ソース定義を指定するためのビジュアル エディターである [新しいデータ ソース] に移動します。

    次のスクリーンショットは、ポータルでこの機能が見つかる場所を示したものです。

    データのインポート ウィザードのデータ ソース構成のスクリーンショット。

  3. [新しいデータ ソース] フォームで、必須フィールドに入力し、[削除の追跡] チェック ボックスをオンにして、[ネイティブ BLOB の論理的な削除] を選択します。 次に、[保存] をクリックして、データ ソースの作成で機能を有効にします。

    ポータル データ ソースのネイティブの論理的な削除のスクリーンショット。

ネイティブの論理的な削除ポリシーを使用して削除が取り消された BLOB のインデックスを再作成する

論理的に削除された BLOB を BLOB ストレージに復元する場合、インデクサーでインデックスが常に再作成されるとは限りません。 これは、インデクサーで BLOB の LastModified タイムスタンプを使用してインデックス作成が必要かどうかが判断されるためです。 論理的に削除された BLOB の削除が取り消されたとき、その LastModified タイムスタンプは更新されないため、インデクサーによって最新の LastModified タイムスタンプを持つ BLOB が既に処理されている場合、削除が取り消された BLOB のインデックスは再作成されません。

削除が取り消された BLOB のインデックス再作成が確実に行われるようにするには、BLOB の LastModified タイムスタンプを更新する必要があります。 これを行う 1 つの方法は、その BLOB のメタデータを保存することです。 メタデータを変更する必要はありませんが、メタデータを再保存すると BLOB の LastModified タイムスタンプが更新され、インデクサーでそれを選択する必要があることが認識されます。

カスタム メタデータを使用した論理的な削除方法

この方法ではカスタム メタデータを使用して、検索ドキュメントをインデックスから削除する必要があるかどうかを示します。 ここでは、インデックスから検索ドキュメントを削除した後、Azure Storage でファイルを削除するという 2 つの個別のアクションが必要です。

この機能は一般提供されています。

Azure Storage と Azure AI Search の両方で実行する手順がありますが、その他の機能の依存関係はありません。

  1. Azure Storage では、カスタム メタデータのキーと値のペアをファイルに追加して、ファイルに削除のフラグが付けられていることを示します。 たとえば、プロパティに "IsDeleted" という名前を指定し、それを false に設定できます。 ファイルを削除する場合は、true に変更します。

  2. Azure AI Search では、データソースの定義を編集して "dataDeletionDetectionPolicy" プロパティを含めます。 たとえば、次のポリシーでは、ファイルのメタデータ プロパティ IsDeleted の値が true のときに、そのファイルが削除されるものと見なされます。

    PUT https://[service name].search.windows.net/datasources/file-datasource?api-version=2024-07-01
{
    "name" : "file-datasource",
    "type" : "azurefile",
    "credentials" : { "connectionString" : "<your storage connection string>" },
    "container" : { "name" : "my-share", "query" : null },
    "dataDeletionDetectionPolicy" : {
        "@odata.type" :"#Microsoft.Azure.Search.SoftDeleteColumnDeletionDetectionPolicy",
        "softDeleteColumnName" : "IsDeleted",
        "softDeleteMarkerValue" : "true"
    }
}

  3. インデクサーを実行します。 インデクサーがファイルを処理し、検索インデックスからドキュメントを削除したら、Azure Storage で物理ファイルを削除できます。

削除が取り消された BLOB とファイルのインデックスを再作成する

元の物理的なソース ファイルが Azure Storage にまだ存在する場合は、論理的な削除を取り消すことができます。

  1. Azure Storage で BLOB またはファイルの "softDeleteMarkerValue" : "false" を変更します。

  2. BLOB またはファイルの LastModified タイムスタンプを確認して、最後のインデクサーの実行よりも新しいものにします。 既存のメタデータを再保存することで、強制的に現在の日付と時刻に更新することができます。

  3. インデクサーを実行します。

次のステップ