Azure AI 검색에서 인덱스 삭제 및 다시 빌드
이 문서에서는 Azure AI 검색 인덱스를 삭제하고 다시 빌드하는 방법을 설명합니다. 다시 빌드가 필요한 상황을 설명하고 진행 중인 쿼리 요청에 대한 다시 빌드의 영향을 완화하기 위한 권장 사항을 제공합니다. 자주 다시 빌드해야 하는 경우 인덱스 별칭을 사용하여 애플리케이션이 가리키는 인덱스를 보다 쉽게 전환할 수 있도록 하는 것이 좋습니다.
인덱스 디자인을 반복할 때 개발 중에 인덱스를 삭제한 후 다시 빌드하는 것이 일반적입니다. 대부분의 개발자는 다시 인덱싱 속도를 높이기 위해 데이터의 작은 대표 샘플을 사용하여 작업합니다.
다시 빌드해야 하는 수정 사항
다음 표에서는 인덱스 삭제 및 다시 빌드가 필요한 수정 사항을 나열합니다.
| 작업 | 설명 |
|---|---|
| 필드 삭제 | 필드의 모든 추적을 실제로 제거하려면 인덱스를 다시 작성해야 합니다. 즉시 다시 빌드하는 것이 실용적이지 않은 경우 애플리케이션 코드를 수정하여 더 이상 사용되지 않는 필드에서 액세스를 리디렉션하거나 searchFields를 사용하고 쿼리 매개 변수를 선택하여 검색하고 반환할 필드를 선택할 수 있습니다. 실제로 필드 정의와 콘텐츠는 다음 번에 의심스러운 필드를 생략하는 스키마를 적용할 때 다시 작성이 수행될 때까지 인덱스에 남아 있습니다. |
| 필드 정의 변경 | 필드 이름, 데이터 형식 또는 특정 인덱싱 특성(검색 가능, 필터링 가능, 정렬 가능, 패싯 가능)을 수정하려면 전체적으로 다시 빌드해야 합니다. |
| 필드에 분석기 할당 | 분석기는 인덱스에 정의되어 필드에 할당된 다음, 인덱싱 중에 호출되어 토큰 생성 방법을 알려줍니다. 언제든지 새 분석기 정의를 인덱스에 추가할 수 있지만, 분석기 할당은 필드를 만들 때만 가능합니다. 분석기와 indexAnalyzer 둘 다 그렇습니다. searchAnalyzer 속성은 예외입니다(이 속성을 기존 필드에 할당 가능). |
| 인덱스의 분석기 정의 업데이트 또는 삭제 | 전체 인덱스를 다시 작성하지 않는 한 인덱스의 기존 분석기 구성(분석기, 토크나이저, 토큰 필터 또는 char 필터)을 삭제 또는 변경할 수 없습니다. |
| 제안기에 필드 추가 | 필드가 이미 존재하고 이를 Suggesters 구문에 추가하려면 인덱스를 다시 빌드합니다. |
| 계층 전환 | 현재 위치 업그레이드는 지원되지 않습니다. 더 많은 용량이 필요한 경우 새 서비스를 만들고 인덱스를 처음부터 다시 빌드합니다. 이 프로세스를 자동화하는 데 도움이 되도록 이 Azure AI 검색 .NET 샘플 리포지토리의 index-backup-restore 샘플 코드를 사용할 수 있습니다. 이 앱은 일련의 JSON 파일에 인덱스를 백업한 다음 지정하는 검색 서비스에서 인덱스를 다시 만듭니다. |
다시 빌드 요구 사항 없이 수정
기존 실제 구조에 영향을 주지 않으면서 많은 다른 부분을 수정할 수 있습니다. 특히, 다음 변경은 인덱스를 다시 빌드할 필요가 없습니다. 이러한 변경의 경우 변경 사항으로 인덱스 정의를 업데이트할 수 있습니다.
- 새 필드 추가
- 기존 필드의 retrievable 특성 설정
- 기존 indexAnalyzer가 있는 필드에서 searchAnalyzer 업데이트
- 인덱스에 새 분석기 정의 추가(새 필드에 적용할 수 있음)
- 점수 매기기 프로필 추가, 업데이트 또는 삭제
- CORS 설정 추가, 업데이트 또는 삭제
- synonymMaps 추가, 업데이트 또는 삭제
- 의미 체계 구성 추가, 업데이트 또는 삭제
새 필드를 추가할 때 기존의 인덱싱된 문서에는 새 필드에 null 값이 제공됩니다. 나중에 데이터를 새로 고치면 외부 원본 데이터의 값이 Azure AI 검색에서 추가된 null을 대체합니다. 인덱스 콘텐츠 업데이트에 대한 자세한 내용은 문서 추가, 업데이트 또는 삭제를 참조하세요.
인덱스를 다시 작성하는 방법
개발하는 동안 인덱스 스키마는 자주 변경됩니다. 작은 대표 데이터 세트로 신속하게 삭제, 다시 만들기 및 다시 로드될 수 있는 인덱스를 만들어 이를 계획할 수 있습니다.
이미 프로덕션 환경에서 사용되는 애플리케이션의 경우 기존 인덱스와 나란히 실행되는 새 인덱스를 만들어 쿼리 가동 중지 시간을 피하는 것이 좋습니다. 애플리케이션 코드는 새 인덱스에 대한 리디렉션을 제공합니다.
공간을 확인합니다. 검색 서비스에는 서비스 계층에 따라 달라지는 최대 인덱스 수가 적용됩니다. 두 번째 인덱스를 위한 공간이 있는지 확인합니다.
다시 빌드가 필요한지 여부를 확인합니다. 필드를 추가하거나 필드와 관련이 없는 인덱스의 일부를 변경하는 경우 삭제, 다시 만들기 및 완전히 다시 로드하지 않고도 정의를 업데이트할 수 있습니다.
나중에 참조하기 위해 필요한 경우 인덱스 정의를 가져옵니다 .
새 인덱스와 이전 인덱스를 나란히 실행하지 않는다고 가정하고 기존 인덱스를 삭제합니다.
해당 인덱스를 대상으로 하는 모든 쿼리는 즉시 삭제됩니다. 인덱스 삭제는 되돌릴 수 없으며, 필드 컬렉션 및 기타 구성에 대한 실제 스토리지가 제거됩니다. 삭제하기 전에 어떤 영향이 미칠지 생각합니다.
요청 본문에 변경되거나 수정된 필드 정의가 포함된 수정된 인덱스를 만듭니다.
외부 원본의 문서를 사용하는 인덱스를 로드합니다.
인덱스를 만들면 실제 스토리지가 인덱스 스키마의 각 필드에 할당되고 검색 가능한 각 필드에 대해 반전된 인덱스가 생성됩니다. 검색할 수 없는 필드는 필터 또는 식에 사용할 수 있지만, 반전된 인덱스를 갖고 있지 않으며 전체 텍스트 또는 유사 항목 검색이 불가능합니다. 인덱스 다시 작성 시, 사용자가 제공하는 인덱스 스키마에 따라 이러한 반전된 인덱스가 삭제된 후 다시 만들어집니다.
인덱스를 로드할 때 각 필드의 반전된 인덱스가 각 문서의 고유한 토큰화된 모든 단어와 해당 문서 ID에 대한 맵으로 채워집니다. 예를 들어, 호텔 데이터 세트를 인덱싱할 때 City 필드용으로 만든 반전된 인덱스는 Seattle, Portland 등의 용어를 포함할 수 있습니다. City 필드에 Seattle 또는 Portland가 포함된 문서는 해당 용어와 함께 문서 ID가 표시됩니다. 추가, 업데이트 또는 삭제 작업에서 용어 및 문서 ID 목록이 이에 따라 업데이트됩니다.
워크로드 분산
인덱싱이 백그라운드에서 실행되지는 않지만, 검색 서비스가 모든 인덱싱 작업과 진행 중인 쿼리의 균형을 맞춥니다. 인덱싱 중에 포털에서 쿼리 요청을 모니터링하여 쿼리가 적시에 완료되도록 할 수 있습니다.
인덱싱 워크로드로 인해 허용할 수 없는 수준의 쿼리 대기 시간이 발생하는 경우, 성능을 분석하고 이러한 성능 팁을 검토하여 완화할 수 있습니다.
업데이트 확인
첫 번째 문서를 로드하는 즉시 인덱스 쿼리를 시작할 수 있습니다. 문서 ID를 알고 있는 경우 문서 조회 REST API가 특정 문서를 반환합니다. 보다 광범위한 테스트를 위해서는 인덱스가 완전히 로드될 때까지 기다린 다음, 쿼리를 사용하여 보려는 컨텍스트를 확인합니다.
검색 탐색기 또는 REST 클라이언트를 사용하여 업데이트된 콘텐츠를 확인할 수 있습니다.
필드를 추가하거나 이름을 변경한 경우 $select를 사용하여 해당 필드를 반환합니다. search=*&$select=document-id,my-new-field,some-old-field&$count=true