Blob 및 파일을 인덱싱하여 여러 검색 문서 생성
기본적으로 인덱서는 Blob 또는 파일의 콘텐츠를 단일 검색 문서로 처리합니다. 검색 인덱스에서 보다 세부적인 표현을 원하는 경우 parsingMode 값을 설정하여 하나의 Blob 또는 파일에서 여러 검색 문서를 만들 수 있습니다. 많은 검색 문서가 생성되는 parsingMode 값으로는 delimitedText(CSV의 경우)와 jsonArray 또는 jsonLines(JSON의 경우)가 있습니다.
해당 구문 분석 모드를 사용하는 경우 나타나는 새 검색 문서에는 고유한 문서 키가 있어야 하며 해당 값이 어디에서 오는지를 파악하는 데 문제가 발생합니다. 부모 Blob에는 metadata_storage_path property 형식의 고유 값이 하나 이상 있지만, 해당 값이 두 개 이상의 검색 문서에 기여하는 경우 키가 더 이상 인덱스에서 고유하지 않게 됩니다.
이 문제를 해결하기 위해 Blob 인덱서는 단일 Blob 부모에서 만든 각 자식 검색 문서를 고유하게 식별하는 AzureSearch_DocumentKey를 생성합니다. 이 문서에서는 이 기능의 작동 방식에 대해 설명합니다.
일대다 문서 키
인덱스의 각 문서는 문서 키로 고유하게 식별됩니다. 구문 분석 모드가 지정되지 않은 상태에서 검색 문서 키에 대한 인덱서 정의에 명시적 필드 매핑이 없는 경우, Blob 인덱서는 자동으로 metadata_storage_path property를 문서 키로 매핑합니다. 이 기본 매핑을 사용하면 각 Blob이 개별적인 검색 문서로 표시되고, 이 필드 매핑을 직접 만들지 않아도 됩니다(일반적으로 이름과 형식이 동일한 필드만 자동으로 매핑됨).
일대다 검색 문서 시나리오에서는 metadata_storage_path property를 기반으로 하는 암시적 문서 키를 사용할 수 없습니다. 해결 방법으로 Azure AI 검색은 Blob에서 추출된 각 개별 엔터티에 대한 문서 키를 생성할 수 있습니다. 생성된 키의 이름은 AzureSearch_DocumentKey이며 각 검색 문서에 추가됩니다. 인덱서는 각 Blob에서 만들어진 "많은 문서"를 추적하고 시간이 지남에 따라 원본 데이터가 변경될 때 검색 인덱스에 대한 업데이트를 대상으로 지정할 수 있습니다.
기본적으로 키 인덱스 필드에 대한 명시적 필드 매핑을 지정하지 않으면 base64Encode 필드 매핑 함수를 사용하여 AzureSearch_DocumentKey가 매핑됩니다.
예시
다음 필드가 포함된 인덱스 정의를 가정합니다.
idtemperaturepressuretimestamp
그리고 Blob 컨테이너에는 다음 구조의 Blob이 있습니다.
Blob1.json
{ "temperature": 100, "pressure": 100, "timestamp": "2024-02-13T00:00:00Z" }
{ "temperature" : 33, "pressure" : 30, "timestamp": "2024-02-14T00:00:00Z" }
Blob2.json
{ "temperature": 1, "pressure": 1, "timestamp": "2023-01-12T00:00:00Z" }
{ "temperature" : 120, "pressure" : 3, "timestamp": "2022-05-11T00:00:00Z" }
키 필드에 대해 명시적 필드 매핑을 지정하지 않은 상태로 인덱서를 만들고 parsingMode를 jsonLines로 설정하면 다음 매핑이 암시적으로 적용됩니다.
{
"sourceFieldName" : "AzureSearch_DocumentKey",
"targetFieldName": "id",
"mappingFunction": { "name" : "base64Encode" }
}
이렇게 설정하면 다음 그림과 유사한 명확한 문서 키가 생성됩니다(간결성을 위해 단축된 base64로 인코딩된 ID).
| ID | 온도 | pressure | timestamp |
|---|---|---|---|
| aHR0 ... YjEuanNvbjsx | 100 | 100 | 2024-02-13T00:00:00Z |
| aHR0 ... YjEuanNvbjsy | 33 | 30 | 2024-02-14T00:00:00Z |
| aHR0 ... YjIuanNvbjsx | 1 | 1 | 2023-01-12T00:00:00Z |
| aHR0 ... YjIuanNvbjsy | 120 | 3 | 2022-05-11T00:00:00Z |
인덱스 키 필드에 대한 사용자 지정 필드 매핑
인덱스 정의가 이전 예제와 동일하다는 가정하에, Blob 컨테이너에 다음 구조의 Blob이 있다고 가정합니다.
Blob1.json
recordid, temperature, pressure, timestamp
1, 100, 100,"2024-02-13T00:00:00Z"
2, 33, 30,"2024-02-14T00:00:00Z"
Blob2.json
recordid, temperature, pressure, timestamp
1, 1, 1,"20123-01-12T00:00:00Z"
2, 120, 3,"2022-05-11T00:00:00Z"
delimitedText parsingMode를 사용하여 인덱서를 만들 때 다음과 같이 키 필드에 필드 매핑 함수를 설정하는 것이 당연하게 느껴질 수 있습니다.
{
"sourceFieldName" : "recordid",
"targetFieldName": "id"
}
그러나 recordid 필드는 여러 Blob에 걸쳐 고유하지 않으므로 해당 매핑을 통해 4개의 문서가 인덱스에 표시되지 않습니다. 따라서 AzureSearch_DocumentKey 속성에서 적용된 암시적 필드 매핑을 “일대다” 구문 분석 모드의 키 인덱스 필드에 사용하는 것이 좋습니다.
명시적 필드 매핑을 설정하려면 모든 Blob에서 개별 엔터티에 대해 sourceField가 고유한지 확인합니다.
참고 항목
AzureSearch_DocumentKey가 추출된 엔터티당 고유성을 보장하는 데 사용하는 접근 방식은 변경될 수 있으므로 애플리케이션의 요구 사항에 따른 해당 값에 의존해서는 안 됩니다.
데이터에서 인덱스 키 필드 지정
첫 번째 예제에서 매핑이 같이 보이도록 명시적 필드 매핑을 지정하지 않고 이전 예제 및 parsingMode와 동일한 인덱스 정의를 jsonLines으로 설정한다고 했을 때, Blob 컨테이너에 다음 구조가 있는 Blob이 있다고 가정합니다.
Blob1.json
id, temperature, pressure, timestamp
1, 100, 100,"2024-02-13T00:00:00Z"
2, 33, 30,"2024-02-14T00:00:00Z"
Blob2.json
id, temperature, pressure, timestamp
1, 1, 1,"2023-01-12T00:00:00Z"
2, 120, 3,"2022-05-11T00:00:00Z"
각 문서에는 인덱스의 key 필드로 정의된 id 필드가 포함되어 있습니다. 이러한 경우 문서 고유 AzureSearch_DocumentKey가 생성되더라도 문서의 "키"로 사용되지 않습니다. 대신 id 필드 값이 key 필드에 매핑됩니다
이전 예시와 유사하게 id 필드는 여러 Blob에 걸쳐 고유하지 않으므로 해당 매핑을 통해 4개의 문서가 인덱스에 표시되지 않습니다. 이 경우 id를 지정하는 json 항목은 새 문서를 업로드하는 대신 기존 문서에 병합되고 인덱스의 상태는 지정된 id가 있는 최신 읽기 항목을 반영합니다.
다음 단계
Blob 인덱싱의 기본 구조 및 워크플로에 익숙하지 않은 경우, 먼저 Azure AI 검색을 통한 Azure Blob Storage 인덱싱을 검토해야 합니다. 여러 Blob 콘텐츠 형식의 구문 분석 모드에 대한 자세한 내용은 다음 문서를 참조하세요.