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

В Поиск с использованием ИИ 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=2026-08-01-preview
{
    "skillNames" : [
        "#1",
        "#5",
        "#6"
    ]
}

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

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

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

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

API Indexers - Reset Docs (preview) принимает список ключей документов, что позволяет обновить конкретные документы. Если указаны параметры сброса, именно они определяют, что будет обработано, независимо от других изменений в исходных данных. Например, если 20 объектов BLOB были добавлены или обновлены с момента последнего запуска индексатора, но вы сбрасываете только один документ, индексатор обрабатывает только этот документ.

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

Если источником данных является 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=2026-08-01-preview
   {
       "documentKeys" : [
           "1001",
           "4452"
       ]
   }
   

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

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

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

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

   • Если вы хотите, чтобы индексатор прекратил попытки обрабатывать сброшенные документы, задайте для "documentKeys" или "datasourceDocumentIds" пустой список []. В результате этого действия индексатор возобновляет обычную индексацию на основе верхней отметки. Недопустимые ключи документов или ключи документов, которые не существуют, игнорируются.

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

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

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

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

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

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

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

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

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

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

Хотя использование «reset» или «reset docs» может решить эту проблему, команда «reset» может занимать много времени и быть неэффективной для больших наборов данных, а «reset docs» требует определить ключ документа для BLOB-объекта, который нужно обновить.

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

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

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

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

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

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

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

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

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

1. Вызовите Get Indexer Status с помощью предварительной версии 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. Проверьте режим:

   Для параметра "Сброс навыков" задайте значение "mode" indexingAllDocs , так как потенциально затронуты все документы с точки зрения полей, заполняемых обогащением ИИ.

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

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

3. После того как индексатор повторно обработает документы, снова выполните команду Get Indexer Status. Индексатор возвращается в indexingAllDocs режим и обрабатывает все новые или обновленные документы при следующем запуске.

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

Этот раздел относится к службам поиска Standard 3 High Density (S3 HD) и бессерверным службам поиска. Сведения о совокупном поведении квоты и рекомендациях по планированию см. в статье «Выполнение индексатора в Serverless и S3 HD».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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