Запустите или сбросьте индексаторы, функции или документы

В Поиск с использованием ИИ Azure существует несколько способов запуска индексатора:

• Выполните сразу после создания индексатора. Это значение по умолчанию, если индексатор не создается в состоянии "отключен".
• Выполнение по расписанию для вызова выполнения через регулярные интервалы.
• Запустите по запросу с опцией "сброса" или без неё.

В этой статье объясняется, как запускать индексаторы по запросу и без сброса. Он также описывает выполнение индексатора, длительность и параллелизм.

Подключение индексаторов к ресурсам Azure

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

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

Выполнение индексатора

Служба поиска выполняет одно задание индексатора на единицу поиска. Каждая служба поиска начинается с одной единицы поиска, но каждая новая секция или реплика увеличивает количество единиц поиска в вашей службе. Вы можете проверить количество единиц поиска в разделе Essential портала Azure на странице Overview. Если требуется параллельная обработка, убедитесь, что поисковые единицы включают достаточное количество копий. Индексаторы не работают в фоновом режиме, поэтому может возникнуть больше ограничений на запросы, чем обычно, если служба находится под давлением.

На следующем снимке экрана показано количество единиц поиска, определяющее, сколько индексаторов может выполняться одновременно.

После запуска выполнения индексатора невозможно приостановить или остановить его. Выполнение индексатора останавливается, если нет больше документов для загрузки или обновления, или когда достигнуто максимальное ограничение времени выполнения .

Можно одновременно запускать несколько индексаторов при условии достаточной емкости, однако каждый индексатор является единственным экземпляром. Запуск нового экземпляра, когда индексатор уже находится в процессе выполнения, вызывает следующую ошибку: "Failed to run indexer "<indexer name>" error: "Another indexer invocation is currently in progress; concurrent invocations are not allowed."

Среда выполнения индексатора

Задание индексатора выполняется в управляемой среде выполнения. В настоящее время существует две среды:

• Частная среда выполнения выполняется в кластерах поиска, относящихся к службе поиска.

• Мультитенантная среда содержит процессоры содержимого, управляемые и защищенные Microsoft без дополнительных затрат. Эта среда используется для разгрузки вычислительной интенсивной обработки, оставляя ресурсы для конкретных служб доступными для обычных операций. Когда это возможно, большинство навыков выполняется в мультитенантной среде. Это значение по умолчанию.

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

Вы можете предотвратить использование многопользовательской среды в службах Standard2 или более поздней версии, привязав индексатор и набор навыков исключительно к кластерам поиска. executionEnvironment Задайте параметр в определении индексатора, чтобы всегда запускать индексатор в частной среде выполнения.

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

Ограничения индексатора зависят от каждой среды:

¹ Единицы поиска могут быть гибкими сочетаниями секций и реплик, но задания индексатора не привязаны к одному или другому. Другими словами, если у вас есть 12 ищущих единиц, вы можете одновременно выполнять 12 заданий индексатора в режиме частного выполнения, независимо от метода развертывания поисковых единиц.

² Если для обработки всех данных требуется более двух часов, включите обнаружение изменений и запланируйте выполнение индексатора в течение 5 минут, чтобы возобновить индексирование быстро, если он останавливается из-за времени ожидания. Дополнительные стратегии см. в статье Индексирование большого набора данных .

³ "Неопределенное" означает, что ограничение не определяется числом заданий. Некоторые рабочие нагрузки, такие как обработка набора навыков, могут выполняться параллельно, что может привести к множеству заданий, даже если используется только один индексатор. Хотя среда не накладывает ограничения, ограничения индексатора для службы поиска по-прежнему применяются.

Запуск без сброса

Операция запуска индексатора обнаруживает и обрабатывает только то, что необходимо для синхронизации индекса поиска с изменениями в базовом источнике данных. Инкрементное индексирование начинается с поиска внутренней контрольной отметки, чтобы найти последний обновленный документ поиска, который становится начальной точкой для выполнения индексатора на новых и обновленных документах в источнике данных.

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

• служба хранилища Azure имеет встроенное обнаружение изменений с помощью свойства LastModified.

• Другие источники данных, такие как Azure SQL или Azure Cosmos DB, необходимо настроить для обнаружения изменений, прежде чем индексатор сможет считывать новые и обновленные строки.

Если базовое содержимое не изменяется, операция выполнения не влияет. В этом случае журнал выполнения индексатора показывает, что обработано 0\0 документов.

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

Сброс индексаторов

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

Если необходимо перестроить все или часть индекса, используйте API для сброса, доступные на различных уровнях иерархии объектов.

• Сброс индексаторов удаляет отметку прогресса и выполняет полную переиндексацию всех документов
• Ресинхронные индексаторы (предварительная версия) выполняют эффективный частичный переиндекс всех документов
• Сброс документов (предварительная версия) переиндексирует определенный документ или список документов
• Сброс навыков (предварительная версия) вызывает обработку навыков для определенного навыка

После сброса выполните команду Run для повторной обработки новых и существующих документов. Потерянные документы поиска, не имеющие аналогов в источнике данных, не могут быть удалены с помощью сброса или запуска. Если необходимо удалить определенные документы, см. Удаление документов в поисковом индексе или Документы - Индекс.

Как сбросить и запустить индексаторы

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

Фактические действия возникают при выполнении сброса с помощью команды Run:

• Все новые документы, найденные базовым источником, добавляются в индекс поиска.
• Все документы, существующие как в источнике данных, так и в индексе поиска, перезаписываются в индексе поиска.
• Весь обогащенный контент, созданный из наборов навыков, перестроено. Кэш обогащения, если он включен, обновляется.

Как отмечалось ранее, сброс является пассивной операцией: для перестроения индекса необходимо выполнить запрос запуска.

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

Сброс также применяется к операциям создания и обновления. Он не активирует удаление или очистку потерянных документов в индексе поиска. Дополнительные сведения об удалении документов см. в разделе "Документы — индекс".

После сброса индексатора невозможно отменить действие.

POST /indexers/[indexer name]/reset?api-version=[api-version]

POST /indexers/[indexer name]/run?api-version=[api-version]

GET /indexers/[indexer name]/status?api-version=[api-version]

// Reset the indexer if it already exists
try
{
    await indexerClient.GetIndexerAsync(blobIndexer.Name);
    //Rest the indexer if it exsits.
    await indexerClient.ResetIndexerAsync(blobIndexer.Name);
}
catch (RequestFailedException ex) when (ex.Status == 404) { }

await indexerClient.CreateOrUpdateIndexerAsync(blobIndexer);

// Run indexer
Console.WriteLine("Running Blob Storage indexer...\n");

try
{
    await indexerClient.RunIndexerAsync(blobIndexer.Name);
}
catch (RequestFailedException ex) when (ex.Status == 429)
{
    Console.WriteLine("Failed to run indexer: {0}", ex.Message);
}

Инструкция по сбросу навыков (предварительная версия)

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

Для индексаторов с включенным кэшированием можно явно запрашивать обработку обновлений навыков, которые индексатор не может обнаружить. Например, при внесении внешних изменений, таких как изменения пользовательского навыка, можно использовать этот API для повторного запуска навыка. Выходные данные, такие как хранилище знаний или индекс поиска, обновляются с помощью повторно используемых данных из кэша и нового содержимого для обновленного навыка.

Рекомендуется использовать последнюю предварительную версию API.

POST /skillsets/[skillset name]/resetskills?api-version=2025-11-01-preview
{
    "skillNames" : [
        "#1",
        "#5",
        "#6"
    ]
}

Вы можете указать отдельные навыки, как указано в приведенном выше примере, но если любой из этих навыков требует выходных данных из неуказанных навыков (#2–4), неуказанные навыки будут выполняться, если только кэш не сможет предоставить необходимые сведения. Чтобы это было верно, кэшированные обогащения для навыков 2–4 не должны иметь зависимости от #1 (перечислены для сброса).

Если навыки не указаны, выполняется весь набор навыков и если кэширование включено, кэш также обновляется.

Не забудьте выполнить индексатор, чтобы инициировать реальную обработку.

Как сбросить документы (предварительная версия)

Индексаторы — обновление документов (предварительная версия) работают со списком ключей документов, чтобы обновить конкретные документы. Если задано, параметры сброса становятся единственным определяющим фактором того, что обрабатывается, независимо от других изменений в базовых данных. Например, если с момента последнего запуска индексатора были добавлены или обновлены 20 больших двоичных объектов, но вы сбросите только один документ, то обработается только этот документ.

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

Если источник данных Azure Data Lake Storage (ADLS) Gen2, а объекты BLOB связаны с метаданными разрешений, эти разрешения также повторно обрабатываются в индексе поиска, если разрешения изменяются в исходных данных. Дополнительные сведения см. в разделе Повторное индексирование ACL и области RBAC с помощью индексаторов ADLS Gen2.

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

При первом тестировании этого API следующие API помогут вам проверить и протестировать его поведение. Рекомендуется использовать последнюю предварительную версию API.

1. Вызовите Индексаторы - Получить состояние с предварительной версией API для проверки статуса сброса и выполнения. Сведения о запросе сброса вы можете найти в конце ответа на состояние.

2. Вызовите Индексаторы — сброс документов, используя предварительную версию API, чтобы указать, какие документы обрабатывать.

   POST https://[service name].search.windows.net/indexers/[indexer name]/resetdocs?api-version=2025-11-01-preview
   {
       "documentKeys" : [
           "1001",
           "4452"
       ]
   }
   

   • API принимает два типа идентификаторов документов в качестве входных данных: ключи документов, которые однозначно определяют документы в индексе поиска и идентификаторы документов источника данных, которые однозначно определяют документы в источнике данных. Текст должен содержать список ключей документов или список идентификаторов документа источника данных, которые индексатор ищет в источнике данных. При вызове API добавляются ключи документа или идентификаторы исходного документа, которые необходимо сбросить в метаданные индексатора. При следующем запланированном или по запросу запуска индексатора, индексатор обрабатывает только сброшенные документы.

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

   • Ключи документа, предоставленные в запросе, — это значения из индекса поиска, которые могут отличаться от соответствующих полей в источнике данных. Если вы не уверены в значении ключа, отправьте запрос , чтобы вернуть значение. Можно использовать select для возврата только поля ключа документа.

   • Для больших двоичных объектов, которые анализируются в несколько документов поиска (где для синтаксического анализа задано значение jsonLines или jsonArrays, или delimitedText), ключ документа создается индексатором и может быть неизвестным для вас. В этом сценарии запрос ключа документа возвращает правильное значение.

   • Чтобы индексатор перестал пытаться обработать документы сброса, можно задать для "documentKeys" или "datasourceDocumentIds" пустой список "[]". Это приводит к возобновлению регулярного индексирования индексатора на основе высокой водяной отметки. Недопустимые ключи документов или ключи документов, которые не существуют, игнорируются.

3. Вызовите команду Run Indexer (в любой версии API), чтобы обработать указанные документы. Индексируются только те определенные документы.

4. Запустите индексатор во второй раз, чтобы обработать с последнего контрольного момента.

5. Вызовите Search Documents, чтобы проверить обновленные значения и вернуть ключи документов, если вы не уверены в значении. Используйте "select": "<field names>" , если вы хотите ограничить, какие поля отображаются в ответе.

Перезапись списка ключей документа

Вызов API сброса документов несколько раз с различными ключами добавляет новые ключи в список сброса ключей документов. Вызов API с параметром overwrite true перезаписывает текущий список новым:

POST https://[service name].search.windows.net/indexers/[indexer name]/resetdocs?api-version=2025-11-01-preview
{
    "documentKeys" : [
        "200",
        "630"
    ],
    "overwrite": true
}

Как повторно синхронизировать индексаторы (предварительная версия)

Resync Indexers — это предварительный просмотр REST API, который выполняет частичный переиндекс всех документов. Индексатор считается синхронизированным с его источником данных, если определенные поля всех документов в целевом индексе согласованы с данными в источнике данных. Как правило, индексатор достигает синхронизации после успешного начального запуска. Если документ удаляется из источника данных, индексатор остается синхронизированным в соответствии с этим определением. Однако во время следующего запуска индексатора соответствующий документ в целевом индексе удаляется при включении отслеживания удаления.

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

В отличие от этого, для некоторых источников данных, таких как ADLS Gen2, изменение списков управления доступом (ACL) блоба не изменяет время последнего изменения, что делает отслеживание изменений неэффективным, если списки управления доступом должны быть использованы. Следовательно, измененный блоб не переиндексируется при последующем запуске, так как обрабатываются только документы, измененные после последнего уровня верхней границы.

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

Ресинхронные индексаторы предлагают эффективную и удобную альтернативу. Пользователи просто размещают индексатор в режиме повторной синхронизации и указывают содержимое для повторной синхронизации, вызывая API ресинхронных индексаторов. В следующем запуске индексатор проверяет только соответствующую часть данных в источнике и избегает ненужных операций обработки, не связанной с указанными данными. Он также запрашивает существующие документы в целевом индексе и обновляет только документы, которые показывают несоответствия между источником данных и целевым индексом. После выполнения повторной синхронизации индексатор синхронизируется и возвращается к обычному режиму выполнения индексатора для последующих запусков.

Как повторно синхронизировать и запускать индексаторы

1. Вызовите Индексаторы - Повторная синхронизация с помощью предпросмотровой версии API, чтобы указать, какое содержимое необходимо повторно синхронизировать.

   POST https://[service name].search.windows.net/indexers/[indexer name]/resync?api-version=2025-11-01-preview
   {
       "options" : [
           "permissions"
       ]
   }
   

   • Поле options является обязательным. В настоящее время единственным поддерживаемым вариантом является permissions. То есть будут обновлены только поля фильтра разрешений в целевом индексе.

2. Вызовите Run Indexer (в любой версии API), чтобы повторно синхронизировать индексатор.

3. Запустите индексатор во второй раз, чтобы обработать с последнего контрольного момента.

Проверьте состояние сброса "currentState"

Чтобы проверить состояние сброса и узнать, какие ключи документов находятся в очереди на обработку, выполните следующие действия.

1. Вызовите Получить состояние индексатора с использованием предварительной версии API.

   API предварительной версии вернет currentState раздел, найденный в конце ответа.

   "currentState": {
       "mode": "indexingResetDocs",
       "allDocsInitialTrackingState": "{\"LastFullEnumerationStartTime\":\"2021-02-06T19:02:07.0323764+00:00\",\"LastAttemptedEnumerationStartTime\":\"2021-02-06T19:02:07.0323764+00:00\",\"NameHighWaterMark\":null}",
       "allDocsFinalTrackingState": "{\"LastFullEnumerationStartTime\":\"2021-02-06T19:02:07.0323764+00:00\",\"LastAttemptedEnumerationStartTime\":\"2021-02-06T19:02:07.0323764+00:00\",\"NameHighWaterMark\":null}",
       "resetDocsInitialTrackingState": null,
       "resetDocsFinalTrackingState": null,
       "resyncInitialTrackingState": null,
       "resyncFinalTrackingState": null,
       "resetDocumentKeys": [
           "200",
           "630"
       ]
   }
   

2. Проверьте режим:

   Для параметра "Reset Skills" необходимо установить "mode" в indexingAllDocs (поскольку потенциально это касается всех документов в отношении полей, заполненных с помощью обогащения ИИ).

   Для индексаторов Resync режим необходимо задать на indexingResync. Индексатор проверяет все документы и фокусируется на заинтересованных данных в источнике данных и заинтересованных полях в целевом индексе.

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

3. После повторной обработки документов снова запустите команду "Получить статус индексатора". Индексатор возвращается в indexingAllDocs режим и обрабатывает все новые или обновленные документы при следующем запуске.

Проверка квоты среды выполнения индексатора для служб поиска S3 HD

Применяется к службам поиска на ценовом уровне "Стандарт 3 Высокой Плотности" (S3 HD).

Чтобы помочь вам отслеживать время выполнения индексатора относительно 24-часового окна, Get Service Statistics и Get Indexer Status теперь возвращают больше информации в ответе.

Отслеживание накопленной квоты времени выполнения

Отслеживайте совокупное использование среды выполнения индексатора службы поиска и определите, сколько квот среды выполнения осталось в течение текущего 24-часового периода.

Отправьте запрос GET поставщику ресурсов службы поиска. Сведения о настройке клиента REST и получении маркера доступа см. в статье "Подключение к службе поиска".

GET {{search-endpoint}}/servicestats?api-version=2025-11-01-preview 
  Content-Type: application/json
  Authorization: Bearer {{accessToken}}

Ответы включают indexersRuntime свойства, показывающие время начала и окончания, использованные секунды, оставшиеся секунды и общее время выполнения за последние 24 часа.

Отслеживание квоты времени выполнения индексатора

Возвращает ту же информацию для одного индексатора.

GET {{search-endpoint}}/indexers/hotels-sample-indexer/search.status?api-version=2025-11-01-preview 
  Content-Type: application/json
  Authorization: Bearer {{accessToken}}

Ответы включают в себя свойства runtime, показывающие время начала и окончания, использованные секунды и оставшиеся секунды.

Дальнейшие действия

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

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

• Мониторинг состояния индексатора поиска
• Сбор и анализ данных журнала
• Планирование индексатора