인덱서, 기술 또는 문서 실행 또는 초기화

2025-10-03

Azure AI Search에는 인덱서를 실행하는 여러 가지 방법이 있습니다.

인덱서 생성 시 즉시 실행합니다. 인덱서가 "사용 안 함" 상태로 만들어지지 않는 한 기본값입니다.
일정에 따라 실행하여 일정한 간격으로 실행을 호출합니다.
"초기화"을 사용하거나 사용하지 않고 요청 시 실행합니다.

이 문서에서는 초기화를 사용하거나 사용하지 않고 요청 시 인덱서를 실행하는 방법을 설명합니다. 또한 인덱서 실행, 기간 및 동시성에 대해서도 설명합니다.

인덱서가 Azure 리소스에 연결되는 방법

인덱서는 다른 Azure 리소스에 대해 아웃바운드 호출을 수행하는 몇 안 되는 하위 시스템 중 하나입니다. 외부 데이터 원본에 따라 키나 역할을 사용하여 연결을 인증할 수 있습니다.

Azure 역할의 관점에서 인덱서에는 별도의 ID가 없습니다. 검색 엔진에서 다른 Azure 리소스로의 연결은 검색 서비스의 시스템 또는 사용자 할당 관리 ID와 대상 Azure 리소스에 대한 역할 할당을 사용하여 이루어집니다. 인덱서가 가상 네트워크의 Azure 리소스에 연결되는 경우 해당 연결에 대한 공유 프라이빗 링크를 만들어야 합니다.

인덱서 실행

검색 서비스는 검색 단위당 하나의 인덱서 작업을 실행합니다. 모든 검색 서비스는 하나의 검색 단위로 시작하지만 새 파티션 또는 복제본마다 서비스의 검색 단위가 증가합니다. Azure Portal의 개요 페이지에 있는 Essential 섹션에서 검색 단위 수를 확인할 수 있습니다. 동시 처리가 필요한 경우 검색 단위에 충분한 복제본이 포함되어 있는지 확인하세요. 인덱서는 백그라운드에서 실행되지 않으므로 서비스가 압력을 받고 있는 경우 평소보다 더 많은 쿼리 제한이 발생할 수 있습니다.

다음 스크린샷은 한 번에 실행할 수 있는 인덱서 수를 결정하는 검색 단위 수를 보여 줍니다.

인덱서 실행이 시작되면 일시 중지하거나 중지할 수 없습니다. 로드하거나 새로 고칠 문서가 더 이상 없거나 최대 실행 시간 제한에 도달하면 인덱서 실행이 중지됩니다.

용량이 충분하다고 가정할 때 한 번에 여러 인덱서를 실행할 수 있지만 각 인덱서 자체는 단일 인스턴스입니다. 인덱서가 이미 실행 중인 동안 새 인스턴스를 시작하면 다음 오류가 발생합니다. "Failed to run indexer "<indexer name>" error: "Another indexer invocation is currently in progress; concurrent invocations are not allowed."

인덱서 실행 환경

인덱서 작업은 관리되는 실행 환경에서 실행됩니다. 현재 두 가지 환경이 있습니다.

검색 서비스와 관련된 검색 클러스터에서 실행되는 프라이빗 실행 환경입니다.
추가 비용 없이 Microsoft에서 관리하고 보호하는 콘텐츠 프로세서가 있는 다중 테넌트 환경입니다. 이 환경은 계산 집약적 처리를 없애는 데 사용되며 서비스별 리소스는 일상적인 작업에 사용할 수 있게 남아 있습니다. 가능한 경우 대부분의 기술 세트는 다중 테넌트 환경에서 실행됩니다. 이것이 기본값입니다.

계산 집약적인 처리는 대량의 문서 또는 대용량 문서를 처리하는 콘텐츠 프로세서 및 인덱서 작업에서 실행되는 기술 세트를 나타냅니다. 다중 테넌트 콘텐츠 프로세서에 대한 비기술 세트 처리는 추론 및 시스템 정보에 의해 결정되며 고객 제어를 받지 않습니다.

인덱서 및 기술 세트 처리를 검색 클러스터에만 고정하여 Standard2 이상 서비스에서 다중 테넌트 환경의 사용을 방지할 수 있습니다. 항상 프라이빗 실행 환경에서 인덱서가 실행되도록 인덱서 정의에서 매개 변수를 설정합니다.executionEnvironment

IP 방화벽은 다중 테넌트 환경을 차단하므로 방화벽이 있는 경우 다중 테넌트 프로세서 연결을 허용하는 규칙을 만듭니 다.

인덱서 제한은 환경마다 다릅니다.

Workload	최대 기간	최대 작업 수	실행 환경
프라이빗 실행	24시간	검색 단위¹당 인덱서 작업 1개.	인덱싱은 백그라운드에서 실행되지 않습니다. 대신 검색 서비스는 진행 중인 쿼리 및 개체 관리 작업(예: 인덱스 만들기 또는 업데이트)에 대해 모든 인덱싱 작업의 균형을 조정합니다. 인덱서를 실행할 때 인덱싱 볼륨이 크면 일부 쿼리 대기 시간이 발생할 것으로 예상해야 합니다.
Multitenant	2시간 ²	확정되지 않은 ³	콘텐츠 처리 클러스터는 다중 테넌트이므로 수요를 충족하기 위해 콘텐츠 프로세서가 추가됩니다. 주문형 또는 예약된 실행이 지연되는 경우 시스템이 프로세서를 추가하거나 프로세서를 사용할 수 있을 때까지 기다리고 있기 때문일 수 있습니다.

¹ 검색 단위는 파티션과 복제본의 유연한 조합일 수 있지만 인덱서 작업은 둘 중 하나에 연결되어 있지 않습니다. 즉, 12개의 장치가 있는 경우 검색 장치가 배포되는 방식에 관계없이 프라이빗 실행에서 동시에 실행되는 12개의 인덱서 작업을 가질 수 있습니다.

² 모든 데이터를 처리하는 데 2시간 이상이 필요한 경우 변경 검색을 사용하도록 설정하고 인 덱서 가 5분 간격으로 실행되도록 예약하여 시간 초과로 인해 인덱싱이 중지되는 경우 신속하게 인덱싱을 다시 시작합니다. 더 많은 전략은 큰 데이터 집합 인덱싱 을 참조하세요.

³ '미확정'은 한도가 작업 수로 정량화되지 않음을 의미합니다. 기술 세트 처리와 같은 일부 워크로드는 병렬로 실행될 수 있으므로 하나의 인덱서만 관련된 경우에도 많은 작업이 발생할 수 있습니다. 환경에 제약 조건이 없지만 검색 서비스에 대한 인덱서 제한이 계속 적용됩니다.

초기화 없이 실행

인덱서 실행 작업은 검색 인덱스를 기본 데이터 원본의 변경 내용과 동기화하는 데 필요한 항목만 검색하고 처리합니다. 증분 인덱싱은 마지막으로 업데이트된 검색 문서를 찾기 위해 내부 상위 워터 마크 표시를 찾는 것으로 시작합니다. 이 검색 문서는 데이터 원본의 새 문서 및 업데이트된 문서에 대한 인덱서 실행의 시작점이 됩니다.

변경 검색은 데이터 원본에서 새롭거나 업데이트된 항목을 결정하는 데 필수적입니다. 인덱서는 기본 데이터 원본의 변경 검색 기능을 사용하여 데이터 원본에서 새 항목 또는 업데이트된 항목을 확인합니다.

Azure Storage에는 LastModified 속성을 통한 변경 검색 기능이 기본 제공되어 있습니다.
Azure SQL 또는 Azure Cosmos DB와 같은 다른 데이터 원본은 인덱서가 새 행과 업데이트된 행을 읽을 수 있기 전에 변경 검색을 위해 구성되어야 합니다.

기본 콘텐츠가 변경되지 않으면 실행 작업이 적용되지 않습니다. 이 경우 인덱서 실행 기록은 처리된 문서를 나타냅니다 0\0 .

다음 섹션에서 설명한 대로 인덱서가 완전히 다시 처리되도록 다시 설정해야 합니다.

인덱서 다시 설정

초기 실행 후 인덱서는 내부 상위 워터 마크를 통해 인덱싱되는 검색 문서를 추적합니다. 마커는 노출되지 않지만 내부적으로 인덱서는 마커가 마지막으로 중지된 위치를 알고 있습니다.

인덱스의 전체 또는 일부를 다시 빌드해야 하는 경우 개체 계층 구조의 감소 수준에서 사용할 수 있는 초기화 API를 사용합니다.

인덱서 초기화는 상위 워터 마크 표시를 지우고 모든 문서의 전체를 다시 인덱싱합니다.
Resync 인덱서(미리 보기)는 모든 문서에 대해 효율적인 부분 재인덱싱을 수행합니다.
문서 초기화(미리 보기)는 특정 문서 또는 문서 목록의 다시 인덱싱합니다.
기술 초기화(미리 보기)는 특정 기술에 대한 기술 처리를 호출합니다.

초기화 후 실행 명령을 따라 새 문서와 기존 문서를 다시 처리합니다. 데이터 원본에 대응 항목이 없는 분리된 검색 문서는 초기화/실행을 통해 제거할 수 없습니다. 문서를 삭제해야 하는 경우 대신 문서 - 인덱스를 참조하세요.

Note

테이블은 비워 둘 수 없습니다. TRUNCATE TABLE을 사용하여 행을 지우는 경우 인덱서를 다시 설정하고 다시 실행해도 해당 검색 문서가 제거되지 않습니다. 분리된 검색 문서를 제거하려면 삭제 작업으로 문서를 인덱싱해야 합니다.

인덱서를 초기화하고 실행하는 방법

초기화는 상위 워터 마크 표시를 지웁니다. 검색 인덱스의 모든 문서는 인라인 업데이트 또는 기존 콘텐츠로 병합하지 않고 전체 덮어쓰기에 플래그가 지정됩니다. 기술 세트 및 보강 캐싱이 있는 인덱서의 경우 인덱스를 다시 설정하면 기술 세트도 암시적으로 다시 설정됩니다.

실제 작업은 실행 명령으로 초기화를 따를 때 발생합니다.

기본 원본에서 찾은 모든 새 문서가 검색 인덱스에 추가됩니다.
데이터 원본과 검색 인덱스에 모두 있는 모든 문서는 검색 인덱스에서 덮어씌워집니다.
스킬셋에서 생성된 보강 콘텐츠는 재작성됩니다. 보강 캐시가 사용하도록 설정된 경우 새로 고쳐집니다.

앞에서 설명한 것처럼 다시 설정은 수동 작업입니다. 인덱스 다시 작성을 위해 실행 요청에 따라야 합니다.

초기화/실행 작업은 검색 인덱스 또는 지식 저장소, 특정 문서 또는 프로젝션, 초기화에 명시적 또는 암시적으로 기술이 포함된 경우 캐시된 보강에 적용됩니다.

초기화는 만들기 및 업데이트 작업에도 적용됩니다. 검색 인덱스의 고아 상태의 문서를 삭제하거나 정리하는 작업을 유발하지 않습니다. 문서 삭제에 대한 자세한 내용은 문서 - 인덱스를 참조하세요.

인덱서를 초기화한 후에는 작업을 실행 취소할 수 없습니다.

Azure Portal에 로그인하고 검색 서비스 페이지를 엽니다.
개요 페이지에서 인덱서 탭을 선택합니다.
인덱서를 선택합니다.
초기화 명령을 선택한 다음 예를 선택하여 작업을 확인합니다.
페이지를 새로 고쳐 상태를 표시합니다. 항목을 선택하여 세부 정보를 볼 수 있습니다.
실행을 선택하여 인덱서 처리를 시작하거나 예약된 다음 실행을 기다립니다.

다음 예에서는 인덱서 초기화 및 인덱서 실행 REST 호출을 보여 줍니다. 인덱서 상태 가져오기를 사용하여 결과를 확인합니다.

이러한 호출에는 매개 변수나 속성이 없습니다.

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]

다음 예(azure-search-dotnet-samples/multiple-data-sources/)에서는 Azure .NET SDK의 ResetIndexers 및 RunIndexers 메서드를 보여 줍니다.

// 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-08-01-preview
{
    "skillNames" : [
        "#1",
        "#5",
        "#6"
    ]
}

위 예시에 나온 것처럼 개별 기술을 지정할 수 있지만, 해당 기술 가운데 하나라도 목록에 없는 기술(2~4)의 출력이 필요한 경우, 캐시가 필요한 정보를 제공할 수 있는 경우가 아니라면 목록에 없는 기술이 실행됩니다. 이러한 경우를 true로 설정하려면 기술 2~4에 대한 캐시 강화는 기술 1에 대한 종속성이 없어야 합니다(다시 설정을 위해 나열됨).

기술을 지정하지 않은 경우에는 전체 기술 세트가 실행되며 캐싱이 설정되었다면 해당 캐시도 새로 고쳐집니다.

인덱서 실행 후 실제 처리를 호출하는 것을 잊지 마십시오.

문서를 초기화하는 방법(미리 보기)

인덱서 - 문서 다시 설정(미리 보기)은 특정 문서를 새로 고칠 수 있도록 문서 키 목록을 허용합니다. 지정된 경우, 다시 설정된 매개 변수는 기본 데이터의 기타 변경 사항과 상관없이 처리 대상의 유일한 결정자가 됩니다. 예를 들어, 마지막 인덱서 실행 이후 20개의 Blob이 추가되거나 업데이트되었지만 하나의 문서만 초기화한 경우 해당 문서만 처리됩니다.

문서별로 검색 문서의 모든 필드는 데이터 원본의 값과 메타데이터로 새로 고쳐집니다. 새로 고칠 필드를 골라 선택할 수 없습니다.

데이터 원본이 ADLS(Azure Data Lake Storage) Gen2이고 Blob이 권한 메타데이터와 연결된 경우 기본 데이터의 사용 권한이 변경되면 해당 권한도 검색 인덱스에 다시 수집됩니다. 자세한 내용은 ADLS Gen2 인덱서를 사용하여 ACL 및 RBAC 범위 다시 인덱싱을 참조하세요.

문서가 기술 세트를 통해 강화되었으며 캐시된 데이터가 있는 경우, 해당 기술 세트는 지정된 문서만을 위해 호출되고 캐시는 재처리한 문서를 위해 업데이트됩니다.

이 API를 처음으로 테스트하는 경우 다음 API를 사용하여 동작의 유효성을 검사하고 테스트할 수 있습니다. 최신 미리 보기 API를 사용하는 것이 좋습니다.

초기화 상태와 실행 상태를 확인하려면 미리 보기 API 버전으로 인덱서 - 상태 가져오기를 호출합니다. 해당 상태 응답의 마지막에서 다시 설정 요청에 대한 정보를 찾을 수 있습니다.
처리할 문서를 지정하려면 미리 보기 API 버전으로 인덱서 - 문서 초기화를 호출합니다.
```
POST https://[service name].search.windows.net/indexers/[indexer name]/resetdocs?api-version=2025-08-01-preview
{
    "documentKeys" : [
        "1001",
        "4452"
    ]
}
```
- API는 두 가지 유형의 문서 식별자를 입력으로 허용합니다. 즉, 검색 인덱스의 문서를 고유하게 식별하는 문서 키와 데이터 원본의 문서를 고유하게 식별하는 데이터 원본 문서 식별자입니다. 본문에는 인덱서가 데이터 원본에서 찾는 문서 키 목록 또는 데이터 원본 문서 식별자 목록이 포함되어야 합니다. API를 호출하면 인덱서 메타데이터로 다시 설정할 문서 키 또는 데이터 원본 문서 식별자가 추가됩니다. 인덱서의 다음 예약 또는 주문형 실행 시 인덱서는 다시 설정 문서만 처리합니다.
- 문서 키를 사용하여 문서를 재설정하고 인덱서 필드 매핑에서 문서 키를 참조하는 경우 인덱서는 필드 매핑을 사용하여 기본 데이터 원본에서 적절한 필드를 찾습니다.
- 요청을 통해 제공된 문서 키는 검색 인덱스의 값으로, 데이터 원본에서 대응되는 필드와는 다를 수 있습니다. 키 값을 잘 모르는 경우 쿼리를 보내 값을 반환합니다. select을(를) 사용하여 문서 키 필드만 반환할 수 있습니다.
- 여러 검색 문서로 구문 분석되는 Blob의 경우(parsingMode가 jsonLines 또는 jsonArrays 또는 delimitedText로 설정됨) 문서 키는 인덱서에서 생성되며 사용자에게 알려지지 않을 수 있습니다. 이 시나리오에서 문서 키에 대한 쿼리는 올바른 값을 반환합니다.
- 인덱서가 다시 설정 문서 처리를 중지하도록 하려면 "documentKeys" 또는 "datasourceDocumentIds"를 빈 목록 "[]"으로 설정할 수 있습니다. 이로 인해 인덱서가 높은 워터마크에 따라 일반 인덱싱을 재개합니다. 존재하지 않는 잘못된 문서 키 또는 문서 키는 무시됩니다.
인덱서 실행(모든 API 버전)을 호출하여 지정한 문서를 처리합니다. 해당 특정 문서만 인덱싱됩니다.
인덱서 실행을 두 번째로 호출하여 마지막 상위 워터 마크 표시부터 처리합니다.
문서 검색을 호출하여 업데이트된 값을 확인하고 값이 확실하지 않은 경우 문서 키를 반환합니다. 응답으로 표시되는 필드를 제한하려는 경우에는 "select": "<field names>"를 사용합니다.

문서 키 목록 덮어쓰기

서로 다른 키를 사용하여 문서 초기화 API를 여러 번 호출하면 문서 키 초기화 목록에 새 키가 추가됩니다. overwrite 매개 변수를 true로 설정하여 API를 호출하면 현재 목록을 새 목록으로 덮어씁니다.

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

인덱서의 동기화 방법(미리 보기)

다시 동기화 인덱서는 모든 문서의 부분적인 재인덱싱을 수행하는 미리 보기 REST API입니다. 대상 인덱스의 모든 문서의 특정 필드가 데이터 원본의 데이터와 일치하는 경우 인덱서는 해당 데이터 원본과 동기화된 것으로 간주됩니다. 일반적으로 인덱서는 성공적인 초기 실행 후에 동기화를 수행합니다. 데이터가 데이터 원본에서 삭제된 경우 인덱서는 이 정의에 따라 동기화된 상태로 유지됩니다. 그러나 다음 인덱서를 실행하는 동안 삭제 추적을 사용하도록 설정하면 대상 인덱스 내의 해당 문서가 제거됩니다.

데이터 원본에서 문서를 수정하면 인덱서가 동기화되지 않습니다. 일반적으로 변경 내용 추적 메커니즘은 다음 실행 중에 인덱서가 다시 동기화됩니다. 예를 들어 Azure Storage에서 Blob을 수정하면 마지막으로 수정된 시간이 업데이트되므로 업데이트된 시간이 이전 실행에서 설정한 상위 워터 마크를 초과하므로 후속 인덱서 실행에서 다시 인덱싱할 수 있습니다.

반면 ADLS Gen2와 같은 특정 데이터 원본의 경우 Blob의 ACL(액세스 제어 목록)을 변경해도 마지막 수정 시간이 변경되지 않으므로 ACL을 수집해야 하는 경우 변경 내용 추적이 비효율적입니다. 따라서 마지막 기록 지점 이후에 수정된 문서만 처리되므로 수정된 Blob은 이후 실행에서 다시 인덱싱되지 않습니다.

"재설정" 또는 "문서 다시 설정"을 사용하면 이 문제를 해결할 수 있지만, "재설정"은 큰 데이터 세트에 시간이 많이 걸리고 비효율적일 수 있으며 "문서 재설정"을 사용하려면 업데이트용 Blob의 문서 키를 식별해야 합니다.

Resync 인덱서는 효율적이고 편리한 대안을 제공합니다. 사용자는 단순히 인덱서를 다시 동기화 모드로 배치하고 다시 동기화 인덱서 API를 호출하여 다시 동기화할 콘텐츠를 지정합니다. 다음 실행에서 인덱서는 원본에서 데이터의 관련 부분만 검사하고 지정된 데이터와 관련이 없는 불필요한 처리를 방지합니다. 또한 대상 인덱스 내의 기존 문서를 쿼리하고 데이터 원본과 대상 인덱스 간의 불일치를 표시하는 문서만 업데이트합니다. 다시 동기화 실행 후에는 인덱서가 동기화되고 후속 실행에 대한 일반 인덱서 실행 모드로 되돌아갑니다.

인덱서를 다시 동기화하고 실행하는 방법

인덱서 호출 - 재동기화하기 위해 미리 보기 API 버전을 사용하여 어떤 콘텐츠를 다시 동기화할지 지정합니다.
```
POST https://[service name].search.windows.net/indexers/[indexer name]/resync?api-version=2025-08-01-preview
{
    "options" : [
        "permissions"
    ]
}
```
- options 필드는 필수입니다. 현재 지원되는 유일한 옵션은 .입니다 permissions. 즉, 대상 인덱스 내의 권한 필터 필드만 업데이트됩니다.
실행 인덱서(모든 API 버전)를 호출하여 인덱서와 다시 동기화합니다.
인덱서 실행을 두 번째로 호출하여 마지막 상위 워터 마크 표시부터 처리합니다.

초기화 상태 "currentState" 확인

초기화 상태를 확인하고 처리를 위해 대기 중인 문서 키를 확인하려면 다음 단계를 따릅니다.

미리 보기 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"
    ]
}

"모드"를 확인합니다.

기술 초기화의 경우 "모드"를 indexingAllDocs로 설정해야 합니다(AI 보강을 통해 채워진 필드 측면에서 잠재적으로 모든 문서가 영향을 받기 때문).

Resync 인덱서의 경우 "mode"를 indexingResync로 설정해야 합니다. 인덱서는 모든 문서를 확인하고 대상 인덱스 데이터 원본 및 관심 있는 필드의 관심 있는 데이터에 중점을 둡니다.

문서 초기화의 경우 "모드"를 indexingResetDocs로 설정해야 합니다. 인덱서는 문서 초기화 호출에서 제공된 모든 문서 키가 처리될 때까지 이 상태를 유지합니다. 이 시간 동안에는 작업이 진행되는 동안 다른 인덱서 작업이 실행되지 않습니다. 문서 키 목록의 모든 문서를 찾기 위해서는 각 문서의 위치를 찾고 키와 일치하도록 이를 해독할 필요가 있으며 데이터 세트의 규모가 큰 경우 시간이 오래 걸릴 수 있습니다. Blob 컨테이너에 수백 개의 Blob이 포함되어 있고 다시 설정하려는 문서가 마지막에 있는 경우, 인덱서는 다른 모든 항목을 먼저 확인할 때까지 일치하는 Blob을 찾지 못합니다.
문서가 다시 처리된 후 인덱서 상태 가져오기를 다시 실행합니다. 인덱서는 indexingAllDocs 모드로 돌아가고 다음에 실행할 때 새 문서나 업데이트된 문서를 처리합니다.

S3 HD 검색 서비스에 대한 인덱서 런타임 할당량 확인

S3 HD(표준 3 고밀도) 가격 책정 계층의 검색 서비스에 적용됩니다.

이제 24시간 창을 기준으로 인덱서 실행 시간을 모니터링하는 데 도움이 되도록 서비스 통계 가져오기 및 인덱서 상태 가져오기가 응답에서 더 많은 정보를 반환합니다.

누적 런타임 할당량 추적

검색 서비스의 누적 인덱서 런타임 사용량을 추적하고 현재 24시간 창 기간 내에 얼마나 많은 런타임 할당량이 남아 있는지 확인합니다.

검색 서비스 리소스 공급자에게 GET 요청을 보냅니다. REST 클라이언트 설정 및 액세스 토큰 가져오기에 대한 도움말은 검색 서비스에 연결을 참조하세요.

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

응답에는 시작 및 종료 시간, 사용된 시간(초), 남은 시간(초), 지난 24시간 동안의 누적 런타임을 표시하는 indexersRuntime 속성이 포함됩니다.

인덱서 런타임 할당량 추적

단일 인덱서에 대해 동일한 정보를 반환합니다.

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

응답에는 시작 및 종료 시간, 사용된 초, 남은 초를 표시하는 runtime 속성이 포함됩니다.

다음 단계

다시 설정 API는 다음 인덱서 실행의 범위를 알리는 데 사용됩니다. 실제 처리를 위해서는 주문형 인덱서 실행을 호출하거나 작업 완료를 위해 예약된 작업을 허용하도록 해야 합니다. 실행을 완료하면 인덱서는 예약을 통해 처리하든 주문형으로 처리하든 상관없이 정상 처리로 돌아갑니다.

인덱서 작업을 초기화하고 다시 실행한 후 검색 서비스에서 상태를 모니터링하거나 리소스 로깅을 통해 자세한 정보를 가져올 수 있습니다.

피드백

이 페이지가 도움이 되었나요?