Azure AI 검색에서 인덱스 만들기
이 문서에서는 검색 인덱스에 대한 스키마를 정의하고 이를 검색 서비스에 푸시하는 단계를 알아봅니다. 인덱스를 만들면 검색 서비스에 물리적 데이터 구조가 설정됩니다. 인덱스가 존재하면 별도의 작업으로 인덱스를 로드합니다.
필수 조건
키 기반 인증을 위해 Search Service 기여자 또는 관리 API 키로 권한을 작성합니다.
인덱싱하려는 데이터 이해. 검색 인덱스는 검색 가능하게 만들려는 외부 콘텐츠를 기반으로 합니다. 검색 가능한 콘텐츠는 인덱스의 필드로 저장됩니다. Azure AI Search에서 검색 가능하고, 검색 가능하고, 필터링 가능하고, 패싯 가능하고, 정렬 가능한 원본 필드를 명확하게 파악해야 합니다. 지침은 스키마 검사 목록을 참조하세요.
또한 인덱스에서 문서 키(또는 ID)로 사용할 수 있는 원본 데이터의 고유 필드도 있어야 합니다.
안정적인 인덱스 위치. 기본적으로 기존 인덱스를 다른 검색 서비스로 이동할 수 없습니다. 애플리케이션 요구 사항을 다시 검토하고 기존 검색 서비스(용량 및 지역)가 요구 사항에 충분한지 확인합니다. Azure AI 서비스 또는 Azure OpenAI 에 대한 종속성을 사용하는 경우 필요한 모든 리소스를 제공하는 지역을 선택합니다.
마지막으로, 모든 서비스 계층에는 만들 수 있는 개체 수에 대한 인덱스 한도가 있습니다. 예를 들어 무료 계층을 실험하는 경우 지정된 시간에 인덱스 3개만 있을 수 있습니다. 인덱스 자체에는 벡터 제한과 단순 필드 수와 복잡한 필드 수에 대한 인덱스 제한이 있습니다.
문서 키
검색 인덱스 만들기에는 두 가지 요구 사항이 있습니다. 인덱스는 검색 서비스에 고유한 이름이 있어야 하며 문서 키가 있어야 합니다. 필드의 부울 key 특성을 true로 설정하여 문서 키를 제공하는 필드를 나타낼 수 있습니다.
문서 키는 검색 문서의 고유 식별자이고, 검색 문서는 무언가를 완벽하게 설명하는 필드 컬렉션입니다. 예를 들어, 영화 데이터 세트의 인덱스를 생성하는 경우 검색 문서에는 단일 영화의 제목, 장르 및 기간이 포함됩니다. 동영상 이름은 이 데이터 세트에서 고유하므로 영화 이름을 문서 키로 사용할 수 있습니다.
Azure AI Search에서 문서 키는 문자열이며 인덱싱할 콘텐츠를 제공하는 데이터 원본의 고유 값에서 시작되어야 합니다. 일반적으로 검색 서비스는 키 값을 생성하지 않지만 일부 시나리오(예: Azure 테이블 인덱서)에서는 기존 값을 합성하여 인덱싱되는 문서에 대한 고유 키를 만듭니다. 또 다른 시나리오는 청크 또는 분할된 데이터에 대한 일대다 인덱싱이며, 이 경우 각 청크에 대해 문서 키가 생성됩니다.
신규 및 업데이트된 콘텐츠를 인덱싱하는 증분 인덱싱 중에는 새 키가 있는 들어오는 문서가 추가되지만 기존 키가 있는 들어오는 문서는 인덱스 필드가 null인지 또는 채워져 있는지 여부에 따라 병합되거나 덮어쓰기됩니다.
문서 키에 대한 중요한 사항은 다음과 같습니다.
- 키 필드의 최대 값 길이는 1,024자입니다.
- 각 인덱스의 최상위 필드 하나만 키 필드로 선택해야 하며 형식
Edm.String이어야 합니다. - 특성의
key기본값은 단순 필드에는 false이고 복합 필드에는 null입니다.
키 필드를 사용하여 문서를 직접 조회하고 특정 문서를 업데이트하거나 삭제할 수 있습니다. 키 필드의 값은 문서를 조회하거나 인덱싱할 때 대/소문자를 구분하는 방식으로 처리됩니다. 자세한 내용은 GET 문서(REST) 및 인덱스 문서(REST)를 참조하세요.
스키마 검사 목록
이 검사 목록을 사용하여 검색 인덱스의 디자인 결정에 도움을 받으세요.
인덱스 및 필드 이름이 명명 규칙을 준수하도록 명명 규칙을 검토합니다.
지원되는 데이터 형식을 검토합니다. 데이터 형식은 필드 사용 방식에 영향을 줍니다. 예를 들어 숫자 콘텐츠는 필터링할 수 있지만 전체 텍스트를 검색할 수는 없습니다. 가장 일반적인 데이터 형식은 전체 텍스트 검색 엔진을 사용하여 토큰화되고 쿼리되는 검색 가능한 텍스트에 대한
Edm.String입니다. 벡터 필드의 가장 일반적인 데이터 형식은Edm.Single이지만 다른 형식도 사용할 수 있습니다.문서 키를 식별합니다. 문서 키는 인덱스 요구 사항입니다. 고유한 값을 포함하는 원본 데이터 필드에서 채워진 단일 문자열 필드입니다. 예를 들어 Blob Storage에서 인덱싱하는 경우 메타데이터 스토리지 경로가 컨테이너의 각 Blob을 고유하게 식별하기 때문에 문서 키로 사용되는 경우가 많습니다.
인덱스에서 검색 가능한 콘텐츠를 제공하는 데이터 원본의 필드를 식별합니다.
검색 가능한 벡터가 아닌 콘텐츠에는 전체 텍스트 검색 엔진을 사용하여 쿼리되는 짧거나 긴 문자열이 포함됩니다. 콘텐츠가 자세한 정보(작은 구 또는 더 큰 청크)인 경우 다양한 분석기로 실험하여 텍스트 토큰화 방법을 확인합니다.
검색 가능한 벡터 콘텐츠는 수학적 표현으로 존재하는 이미지나 텍스트(모든 언어)일 수 있습니다. 좁은 데이터 형식이나 벡터 압축을 사용하여 벡터 필드를 더 작게 만들 수 있습니다.
필드(예:
retrievable또는filterable)에 설정된 특성은 검색 동작과 검색 서비스에서 인덱스의 실제 표현을 모두 결정합니다. 필드를 특성화해야 하는 방법을 결정하는 것은 많은 개발자에게 반복적인 프로세스입니다. 반복 속도를 높이려면 쉽게 삭제하고 다시 빌드할 수 있도록 샘플 데이터로 시작합니다.필터로 사용할 수 있는 원본 필드를 식별합니다. 숫자 콘텐츠와 짧은 텍스트 필드, 특히 반복 값이 있는 필드가 좋은 옵션입니다. 필터로 작업할 때는 다음을 기억하세요.
필터는 벡터 및 비벡터 쿼리에서 사용할 수 있지만 필터 자체는 인덱스의 영숫자(비벡터) 필드에 적용됩니다.
필터링 가능한 필드는 패싯 탐색에 선택적으로 사용할 수 있습니다.
필터링 가능한 필드는 임의의 순서로 반환되며 관련성 점수 매기기를 거치지 않으므로 정렬 가능하도록 만드는 것이 좋습니다.
벡터 필드의 경우 벡터 검색 구성과 탐색 경로 만들기 및 포함 공간 채우기에 사용되는 알고리즘을 지정합니다. 자세한 내용은 벡터 필드 추가를 참조하세요.
벡터 필드에는 사용할 알고리즘 및 벡터 압축과 같이 벡터가 아닌 필드에는 없는 추가 속성이 있습니다.
벡터 필드는 정렬, 필터링, 패싯 등 벡터 데이터에 유용하지 않은 특성을 생략합니다.
벡터가 아닌 필드의 경우 기본 분석기(
"analyzer": null)를 사용할지 아니면 다른 분석기를 사용할지 결정합니다. 분석기는 인덱싱 및 쿼리 실행 중에 텍스트 필드를 토큰화하는 데 사용됩니다.다국어 문자열의 경우 언어 분석기를 사용하는 것이 좋습니다.
하이픈이 추가된 문자열이나 특수 문자의 경우 특수 분석기를 사용하는 것이 좋습니다. 일례로 필드의 전체 내용을 단일 토큰으로 취급하는 키워드를 들 수 있습니다. 이 동작은 우편 번호, ID 및 일부 제품 이름과 같은 데이터에 유용합니다. 자세한 내용은 특수 문자를 사용하는 부분 용어 검색 및 패턴을 참조하세요.
참고 항목
전체 텍스트 검색은 인덱싱 중에 토큰화된 용어에 대해 수행됩니다. 쿼리가 예상 한 결과를 반환하지 못하는 경우 토큰화를 테스트하여 검색하는 문자열이 실제로 존재하는지 확인합니다. 문자열에서 여러 분석기를 시도하여 다양한 분석기에서 토큰이 생성되는 방법을 확인할 수 있습니다.
필드 정의 구성
필드 컬렉션은 검색 문서의 구조를 정의합니다. 모든 필드에는 이름, 데이터 형식 및 특성이 있습니다.
필드를 검색 가능, 필터링 가능, 정렬 가능 또는 패싯 가능으로 설정하면 인덱스 크기 및 쿼리 성능에 영향을 줍니다. 쿼리 식에서 참조할 수 없는 필드에는 이러한 특성을 설정하지 마세요.
필드를 검색 가능, 필터링 가능, 정렬 가능 또는 패싯 가능으로 설정하지 않으면 쿼리 식에서 필드를 참조할 수 없습니다. 이는 쿼리에 사용되지 않지만 검색 결과에 필요한 필드에 적합합니다.
REST API에는 데이터 형식을 기반으로 하는 기본 특성이 있으며, Azure Portal의 가져오기 마법사에서도 사용됩니다. Azure SDK에는 기본값이 없지만 문자열에 대한 SearchableField 및 기본 형식의 SimpleField와 같은 속성과 동작을 통합하는 필드 서브클래스가 있습니다.
REST API에 대한 기본 필드 특성은 다음 표에 요약되어 있습니다.
| 데이터 형식 | 검색 가능 | 조회 가능 | 필터 가능 | 패싯 가능 | 정렬 가능 | 보관됨 |
|---|---|---|---|---|---|---|
Edm.String |
✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Collection(Edm.String) |
✅ | ✅ | ✅ | ✅ | ❌ | ✅ |
Edm.Boolean |
❌ | ✅ | ✅ | ✅ | ✅ | ✅ |
Edm.Int32, , Edm.Int64Edm.Double |
❌ | ✅ | ✅ | ✅ | ✅ | ✅ |
Edm.DateTimeOffset |
❌ | ✅ | ✅ | ✅ | ✅ | ✅ |
Edm.GeographyPoint |
✅ | ✅ | ✅ | ❌ | ✅ | ✅ |
Edm.ComplexType |
✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Collection(Edm.Single) 및 기타 모든 벡터 필드 형식 |
✅ | ✅ 또는 ❌ | ❌ | ❌ | ❌ | ✅ |
또한 문자열 필드는 선택적으로 분석기 및 동의어 맵과 연결할 수 있습니다. 필터링 가능, 정렬 가능 또는 패싯 가능 형식 Edm.String 의 필드는 길이가 최대 32킬로바이트일 수 있습니다. 이러한 필드의 값은 단일 검색 용어로 처리되고 Azure AI Search에서 용어의 최대 길이는 32KB이기 때문입니다. 이보다 많은 텍스트를 단일 문자열 필드에 저장해야 하는 경우 인덱스 정의에서 필터링 가능하고 정렬 가능하며 패싯 가능을 false 명시적으로 설정해야 합니다.
벡터 필드는 차원 및 벡터 프로필과 연결되어야 합니다. 포털에서 가져오기 및 벡터화 마법사를 사용하여 벡터 필드를 추가하면 검색 가능한 기본값이 true이고, 그렇지 않으면 REST API를 사용하는 경우 false입니다.
필드 특성은 다음 표에 설명되어 있습니다.
| attribute | 설명 |
|---|---|
| name | 필수입니다. 인덱스 또는 부모 필드의 필드 컬렉션 내에서 고유해야 하는 필드의 이름을 설정합니다. |
| type | 필수입니다. 필드의 데이터 형식을 설정합니다. 필드는 단순하거나 복잡할 수 있습니다. 단순 필드는 텍스트나 Edm.Int32 정수와 같은 Edm.String 기본 형식입니다. 복합 필드에 는 단순하거나 복잡한 하위 필드가 있을 수 있습니다. 이렇게 하면 개체 및 개체 배열을 모델링할 수 있으므로 대부분의 JSON 개체 구조를 인덱스에 업로드할 수 있습니다. 지원되는 형식의 전체 목록은 지원되는 데이터 형식을 참조하세요. |
| key | 필수입니다. 필드 값이 인덱스의 문서를 고유하게 식별하도록 지정하려면 이 특성을 true로 설정합니다. 자세한 내용은 이 문서의 문서 키를 참조하세요. |
| retrievable | 검색 결과에서 필드를 반환할 수 있는지 여부를 나타냅니다. 필드를 필터, 정렬 또는 채점 메커니즘으로 사용하지만 최종 사용자에게 필드를 표시하지 않으려면 이 특성을 false 설정합니다. 이 특성은 true 키 필드의 특성이어야 하며 복잡한 필드의 특성이어야 null 합니다. 이 특성은 기존 필드에서 변경할 수 있습니다. 검색 가능을 설정해 true 도 인덱스 스토리지 요구 사항이 증가하지 않습니다. 기본값은 true 단순 필드 및 null 복합 필드에 대한 것입니다. |
| searchable | 필드가 전체 텍스트 검색 가능하고 검색 쿼리에서 참조할 수 있는지 여부를 나타냅니다. 즉, 인덱싱 중에 단어 분리와 같은 어휘 분석을 거칩니다. 검색 가능한 필드를 "Sunny day"와 같은 값으로 설정하면 내부적으로 개별 토큰 "sunny" 및 "day"로 정규화됩니다. 이렇게 하면 이러한 용어를 전체 텍스트로 검색할 수 있습니다. 형식 Edm.String 의 필드이거나 Collection(Edm.String) 기본적으로 검색할 수 있습니다. 이 특성은 false 다른 문자열이 아닌 데이터 형식의 단순 필드에 대한 것이어야 하며 복합 필드여야 null 합니다. 검색 가능한 필드는 Azure AI Search가 해당 필드의 내용을 처리하고 보조 데이터 구조로 구성하여 성능 검색을 수행하기 때문에 인덱스에 추가 공간을 사용합니다. 인덱스의 공간을 절약하고 검색에 필드를 포함할 필요가 없는 경우 검색 가능 false항목을 .로 설정합니다. 자세한 내용은 Azure AI Search에서 전체 텍스트 검색이 작동하는 방식을 참조하세요. |
| filterable | 쿼리에서 $filter 필드를 참조할 수 있도록 설정할지 여부를 나타냅니다. 필터링 가능 항목은 문자열 처리 방식에서 검색 가능한 항목과 다릅니다. 형식 Edm.String 또는 Collection(Edm.String) 필터링 가능한 필드는 어휘 분석을 거치지 않으므로 정확한 일치 항목에 대해서만 비교가 가능합니다. 예를 들어 이러한 필드를 f "Sunny day" $filter=f eq 'sunny' 로 설정하면 일치하는 항목을 찾지 못하지만 $filter=f eq 'Sunny day' 이 특성은 복잡한 필드의 특성이어야 null 합니다. 기본값은 true 단순 필드 및 null 복합 필드에 대한 것입니다. 인덱스 크기를 줄이려면 필터링하지 않을 필드에 이 특성을 false 설정합니다. |
| 정렬 가능 | 식에서 $orderby 필드를 참조할 수 있도록 설정할지 여부를 나타냅니다. 기본적으로 Azure AI Search는 점수를 기준으로 결과를 정렬하지만, 대부분의 환경에서 사용자는 문서의 필드를 기준으로 정렬하려고 합니다. 단순 필드는 단일 값인 경우에만 정렬할 수 있습니다(부모 문서의 범위에 단일 값이 있음). 단순 컬렉션 필드는 다중값이므로 정렬할 수 없습니다. 복합 컬렉션의 단순 하위 필드도 다중 값이므로 정렬할 수 없습니다. 즉, 직계 부모 필드이든 상위 필드이든 관계없이 복합 컬렉션입니다. 복합 필드는 정렬할 수 없으며 정렬 가능한 특성은 이러한 필드에 대해 있어야 합니다 null . 정렬 가능의 기본값은 true 단일 값 단순 필드, false 다중값 단순 필드 및 null 복합 필드에 대한 것입니다. |
| 패싯 가능 | 패싯 쿼리에서 필드를 참조할 수 있도록 설정할지 여부를 나타냅니다. 일반적으로 범주별 적중 횟수를 포함하는 검색 결과 프레젠테이션에 사용됩니다(예: 디지털 카메라를 검색하고 브랜드별, 메가픽셀별, 가격별 적중 항목 보기). 이 특성은 복잡한 필드의 특성이어야 null 합니다. 형식 Edm.GeographyPoint 필드이거나 Collection(Edm.GeographyPoint) 패싯할 수 없습니다. 기본값은 true 다른 모든 단순 필드에 대한 것입니다. 인덱스 크기를 줄이려면 이 특성을 false 패싯하지 않는 필드로 설정합니다. |
| 분석기 | 인덱싱 및 쿼리 작업 중에 문자열을 토큰화하기 위한 어휘 분석기를 설정합니다. 이 속성의 유효한 값에는 언어 분석기, 기본 제공 분석기 및 사용자 지정 분석기가 포함됩니다. 기본값은 standard.lucene입니다. 이 특성은 검색 가능한 문자열 필드에만 사용할 수 있으며 searchAnalyzer 또는 indexAnalyzer와 함께 설정할 수 없습니다. 분석기를 선택하고 인덱스로 필드를 만든 후에는 필드에 대해 변경할 수 없습니다. 복합 필드의 경우여야 null 합니다. |
| searchAnalyzer | 인덱싱 및 쿼리에 대해 다른 어휘 분석기를 지정하려면 indexAnalyzer와 함께 이 속성을 설정합니다. 이 속성을 사용하는 경우 분석기를 null 설정하고 indexAnalyzer가 허용되는 값으로 설정되어 있는지 확인합니다. 이 속성의 유효한 값에는 기본 제공 분석기 및 사용자 지정 분석기가 포함됩니다. 이 특성은 검색 가능한 필드에만 사용할 수 있습니다. 검색 분석기는 쿼리 시간에만 사용되므로 기존 필드에서 업데이트할 수 있습니다. 복합 필드의 경우여야 null 합니다.]. |
| indexAnalyzer | 인덱싱 및 쿼리에 대해 다른 어휘 분석기를 지정하려면 searchAnalyzer와 함께 이 속성을 설정합니다. 이 속성을 사용하는 경우 분석기를 null 설정하고 searchAnalyzer가 허용되는 값으로 설정되어 있는지 확인합니다. 이 속성의 유효한 값에는 기본 제공 분석기 및 사용자 지정 분석기가 포함됩니다. 이 특성은 검색 가능한 필드에만 사용할 수 있습니다. 인덱스 분석기를 선택한 후에는 필드에 대해 변경할 수 없습니다. 복합 필드의 경우여야 null 합니다. |
| synonymMaps | 이 필드와 연결할 동의어 맵의 이름 목록입니다. 이 특성은 검색 가능한 필드에만 사용할 수 있습니다. 현재 필드당 하나의 동의어 맵만 지원됩니다. 필드에 동의어 맵을 할당하면 해당 필드를 대상으로 하는 쿼리 용어가 동의어 맵의 규칙을 사용하여 쿼리 시간에 확장됩니다. 이 특성은 기존 필드에서 변경할 수 있습니다. null 복합 필드에 대한 빈 컬렉션이거나 비어 있어야 합니다. |
| 필드 | 형식 Edm.ComplexType 의 필드인 경우 하위 필드 목록입니다 Collection(Edm.ComplexType). 단순 필드의 경우 비어 있거나 비어 있어야 null 합니다. 하위 필드를 사용하는 방법과 시기에 대한 자세한 내용은 Azure AI Search에서 복잡한 데이터 형식을 모델링하는 방법을 참조하세요. |
인덱스 만들기
인덱스를 만들 준비가 되면 요청을 보낼 수 있는 검색 클라이언트를 사용합니다. 초기 개발 및 개념 증명 테스트를 위해 Azure Portal 또는 REST API를 사용할 수 있습니다. 그렇지 않으면 Azure SDK를 사용하는 것이 일반적입니다.
개발하는 동안 다시 빌드하는 계획을 자주 세워야 합니다. 물리적 구조는 서비스에서 만들어지므로 대부분 수정하려면 인덱스를 삭제하고 다시 만들어야 합니다. 보다 빠르게 다시 작성할 수 있도록 데이터 하위 집합을 사용하는 방안을 고려해 볼 수 있습니다.
포털을 통한 인덱스 디자인은 숫자 필드에서 전체 텍스트 검색 기능을 허용하지 않는 등의 특정 데이터 형식에 대한 요구 사항 및 스키마 규칙을 적용합니다.
Azure Portal에 로그인합니다.
공간을 확인합니다. 검색 서비스에는 서비스 계층에 따라 달라지는 최대 인덱스 수가 적용됩니다. 두 번째 인덱스를 위한 공간이 있는지 확인합니다.
검색 서비스 개요 페이지에서 검색 인덱스 만들기 옵션 중 하나를 선택합니다.
- 인덱스 추가 - 인덱스 스키마를 지정하기 위해 포함된 편집기
- 가져오기 마법사
이 마법사는 인덱서, 데이터 원본 및 완성된 인덱스를 만드는 엔드투엔드 워크플로입니다. 데이터도 로드합니다. 기능이 필요 이상으로 많다면 인덱스 추가를 대신 사용하세요.
다음 스크린샷은 명령 모음에 인덱스 추가, 데이터 가져오기 및 데이터 가져오기 및 벡터화가 표시되는 위치를 강조 표시합니다.
인덱스를 만든 후에는 왼쪽 탐색 창의 인덱스 페이지에서 인덱스를 다시 찾을 수 있습니다.
팁
포털에서 인덱스를 만든 후 JSON 표현을 복사하여 애플리케이션 코드에 추가할 수 있습니다.
원본 간 쿼리에 대해 corsOptions 설정
인덱스 스키마에는 corsOptions 설정에 대한 섹션이 포함됩니다. 브라우저에서는 모든 원본 간 요청을 차단하므로 기본적으로 클라이언트 쪽 JavaScript에서 API를 호출할 수 없습니다. 인덱스에 대한 원본 간 쿼리를 허용하려면 corsOptions 특성을 설정하여 CORS(원본 간 리소스 공유)를 사용하도록 설정합니다. 보안상의 이유로 쿼리 API에서만 CORS가 지원됩니다.
"corsOptions": {
"allowedOrigins": [
"*"
],
"maxAgeInSeconds": 300
CORS에 다음 속성을 지정할 수 있습니다.
allowedOrigins(필수): 인덱스에 액세스할 수 있는 원본의 목록입니다. 이러한 원본에서 제공되는 JavaScript 코드는 인덱스를 쿼리할 수 있습니다(호출자가 유효한 키를 제공하거나 호출자에 권한이 있다고 가정). 각 원본은 보통
protocol://<fully-qualified-domain-name>:<port>형식이지만<port>는 대개 생략됩니다. 자세한 내용은 원본 간 리소스 공유(Wikipedia)를 참조하세요.모든 원본에 대한 액세스를 허용하려면 allowedOrigins 배열에서
*를 단일 항목으로 포함합니다. 프로덕션 검색 서비스에는 권장되지 않지만 개발 및 디버깅에 유용한 경우가 많습니다.maxAgeInSeconds(선택): 브라우저는 이 값을 사용하여 CORS 실행 전 응답을 캐시할 기간(초)을 결정합니다. 이 값은 음수가 아닌 정수여야 합니다. 캐시 기간이 길수록 성능이 향상되지만 CORS 정책이 적용되는 시간이 연장됩니다. 이 값을 설정하지 않으면 기본 기간(5분)이 사용됩니다.
기존 인덱스에 허용되는 업데이트
인덱스 만들기는 검색 서비스에 물리적 데이터 구조(파일 및 반전된 인덱스)를 만듭니다. 인덱스가 만들어지면 인덱스 만들기 또는 업데이트를 사용하여 변경 내용을 적용할 수 있는 기능은 수정으로 인해 실제 구조가 무효화되는지 여부에 따라 결정됩니다. 인덱스에서 필드를 만든 후에는 대부분의 필드 특성을 변경할 수 없습니다.
애플리케이션 코드에서 변동을 최소화하기 위해 검색 인덱스에 대한 안정적인 참조 역할을 하는 인덱스 별칭을 만들 수 있습니다. 인덱스 이름으로 코드를 업데이트하는 대신 최신 인덱스 버전을 가리키도록 인덱스 별칭을 업데이트할 수 있습니다.
디자인 프로세스의 변동을 최소화하기 위해 다음 표에서는 스키마의 고정 요소와 유연한 요소를 설명합니다. 고정 요소를 변경하려면 인덱스를 다시 빌드해야 하는 반면, 유연한 요소는 물리적 구현에 영향을 주지 않고 언제든지 변경할 수 있습니다. 자세한 내용은 인덱스 업데이트 또는 다시 작성을 참조하세요.
| 요소 | 업데이트 가능 여부 |
|---|---|
| 이름 | 아니요 |
| 키 | 아니요 |
| 필드 이름 및 형식 | 아니요 |
| 필드 특성(검색 가능, 필터링 가능, 패싯 가능, 정렬 가능) | 아니요 |
| 필드 특성(가져오기 가능) | 예 |
| 저장됨(벡터에 적용됨) | 아니요 |
| 분석기 | 인덱스에서 사용자 지정 분석기를 추가하고 수정할 수 있습니다. 문자열 필드의 분석기 할당과 관련하여 searchAnalyzer만 수정할 수 있습니다. 다른 모든 할당 및 수정에는 다시 빌드가 필요합니다. |
| 점수 매기기 프로필 | 예 |
| 확인기 | 아니요 |
| CORS(원본 간 리소스 공유) | 예 |
| 암호화 | 예 |
| 동의어 맵 | 예 |
| 의미 체계 구성 | 예 |
다음 단계
다음 링크를 사용하여 인덱스로 추가할 수 있는 특수한 기능에 대해 알아봅니다.
인덱스 로드 또는 업데이트에 다음 링크를 사용합니다.