Обнаружение изменений и удалений с помощью индексаторов для службы хранения Azure в Azure AI Search

После создания первоначального индекса поиска вы можете захотеть, чтобы последующие задания индексатора обрабатывали только новые и измененные документы. Для индексированного содержимого, полученного из служба хранилища Azure, обнаружение изменений происходит автоматически, так как индексаторы отслеживают последнее обновление с помощью встроенных меток времени для объектов и файлов в служба хранилища Azure.

Хотя обнаружение изменений считается само собой разумеющимся, обнаружение удаления – нет. Индексатор не отслеживает удаление объектов в источниках данных. Чтобы избежать появления бесхозных документов поиска, можно реализовать стратегию "мягкого удаления", которая сначала приводит к удалению документов поиска, а физическое удаление в Azure Storage выполняется следующим шагом.

Существует два способа реализации стратегии мягкого удаления:

• Мягкое удаление встроенных Blob-объектов применяется только к хранилищу Blob.
• Мягкое удаление с использованием пользовательских метаданных

Стратегия обнаружения удаления должна применяться с самого первого запуска индексатора. Если вы не установили политику удаления до первоначального запуска, все документы, которые были удалены до реализации политики, останутся в индексе, даже если вы добавите политику в индексатор позже и сбросите ее. Если это произошло, рекомендуется создать новый индекс с помощью нового индексатора, гарантируя, что политика удаления выполняется с самого начала.

Предпосылки

• Используйте индексатор хранилища Azure для хранилища Blob, хранилища таблиц, файлового хранилища или Data Lake Storage Gen2

• Используйте согласованные ключи документов и структуру файлов. Изменение ключей документов или имен каталогов и путей (применяется к ADLS 2-го поколения) нарушает внутренние данные отслеживания, используемые индексаторами, чтобы узнать, какое содержимое индексировано, и когда он был последним индексирован.

Обратимое удаление собственного BLOB-объекта

Для этого подхода к обнаружению удаления служба поиска ИИ Azure зависит от функции обратимого удаления большого двоичного объекта в Хранилище BLOB-объектов Azure, чтобы определить, перешли ли большие двоичные объекты в обратимое удаленное состояние. При обнаружении BLOB-объектов в этом состоянии индексатор поиска использует эту информацию для удаления соответствующего документа из индекса.

Требования к встроенному мягкому удалению

• BLOB-объекты должны находиться в контейнере хранилища BLOB-объектов Azure, включая контейнер для BLOB-объектов ADLS Gen2. Политика мягкого удаления собственных BLOB-объектов, присущая службе "Поиск ИИ Azure", не поддерживается для файлов Azure.

• Включение мягкого удаления для BLOB-объектов.

• Ключи документов в индексе должны быть сопоставлены с BLOB-свойством или метаданными BLOB, такими как "metadata_storage_path".

• Вы можете использовать REST API или конфигурацию источника данных индексатора в портале Azure для настройки поддержки обратимого удаления.

• Версионирование BLOB-объектов не должно быть включено в учетной записи хранения. В противном случае встроенное мягкое удаление не поддерживается по замыслу.

Настройка встроенного мягкого удаления

В хранилище Blob, при включении мягкого удаления по требованию, задайте политику хранения значением, значительно превышающим интервал расписания индексатора. Если возникает проблема с индексатором или если у вас много документов для индексирования, у индексатора будет достаточно времени, чтобы постепенно обработать мягко удаленные двоичные объекты. Индексаторы поиска ИИ Azure будут удалять документ из индекса только если они обрабатывают BLOB в состоянии мягкого удаления.

В службе "Поиск ИИ Azure" задайте собственную политику обнаружения обратимого удаления BLOB-объектов в источнике данных. Это можно сделать на портале Azure или с помощью REST API. В следующих инструкциях объясняется, как задать политику обнаружения удаления в портале Azure или с помощью REST API.

PUT https://[service name].search.windows.net/datasources/blob-datasource?api-version=2025-09-01
Content-Type: application/json
api-key: [admin key]
{
   "name" : "blob-datasource",
   "type" : "azureblob",
   "credentials" : { "connectionString" : "<your storage connection string>" },
   "container" : { "name" : "my-container", "query" : null },
   "dataDeletionDetectionPolicy" : {
   "@odata.type" :"#Microsoft.Azure.Search.NativeBlobSoftDeleteDeletionDetectionPolicy"
   }
}

Переиндексировать неудаленные двоичные объекты с помощью наличных политик мягкого удаления.

При восстановлении мягко удаленного двоичного объекта в хранилище Blob индексатор не всегда будет его переиндексировать. Это связано с тем, что индексатор использует метку времени объекта BLOB LastModified, чтобы определить необходимость индексации. Если мягко удаленный большой двоичный объект восстановлен, его LastModified метка времени не обновляется, поэтому, если индексатор уже обработал большие двоичные объекты с более новыми LastModified метками времени, он не будет переиндексировать восстановленный большой двоичный объект.

Чтобы убедиться, что неудаленный объект blob переиндексирован, необходимо обновить метку времени объекта LastModified blob. Один из способов сделать это — повторно сохранить метаданные объекта BLOB. Вам не нужно изменять метаданные, но при повторном сохранении метаданных будет обновлена метка времени LastModified BLOB-объекта, чтобы индексатор знал о том, что его следует выбрать.

Стратегия обратимого удаления с помощью пользовательских метаданных

Этот метод использует пользовательские метаданные, чтобы указать, следует ли удалить документ поиска из индекса. Для этого требуется два отдельных действия: удаление документа поиска из индекса, а затем удаление файла в хранилище Azure.

Эта функция общедоступна.

В службах хранилища Azure и поиска ИИ Azure необходимо выполнить действия, но нет других зависимостей возможностей.

1. В службу хранения Azure добавьте в файл произвольную пару ключ-значение в метаданных, чтобы указать, что файл помечен для удаления. Например, можно присвоить свойству IsDeleted значение false. Если вы хотите удалить файл, измените его на true.

2. В поиске ИИ Azure измените определение источника данных, чтобы включить свойство dataDeletionDetectionPolicy. Например, следующая политика считает, что файл удаляется, если он имеет свойство IsDeleted метаданных со значением true:

   PUT https://[service name].search.windows.net/datasources/file-datasource?api-version=2025-09-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.

Переиндексировать неудаленные блобы и файлы

Обратимое удаление можно отменить, если исходный файл по-прежнему физически существует в хранилище Azure.

1. Измените "softDeleteMarkerValue" : "false" для блоба или файла в службе хранилища Azure.

2. Проверьте метку времени BLOB или файла LastModified, чтобы убедиться, что она более новая, чем при последнем запуске индексатора. Вы можете принудительно обновить текущую дату и время, изменив существующие метаданные.

3. Запустите индексатор.

Ограничения

При использовании сценариев индексирования один ко многим не применяется ни встроенное обратимое удаление, ни обратимое удаление с использованием пользовательских метаданных. Чтобы удалить запись документа, необходимо отправить запрос на удаление в индекс с помощью операции удаления REST API.

Дальнейшие шаги

• Индексаторы в поиске ИИ Azure
• Настройка индексатора BLOB-объектов
• Общие сведения об индексировании BLOB-объектов