참고
Azure AI 검색 Azure 포털, REST API 및 Azure SDK 통해 사용할 수 있습니다. 또한 엔터프라이즈 콘텐츠를 Microsoft Foundry 포털의 에이전트에 대해 재사용 가능한 사용 권한 인식 기술 자료로 변환하는 관리되는 기술 계층인 Foundry IQ를 뒷받침합니다.
중요
기능, 기능 또는 표시된 속성(미리 보기)은 서비스 수준 계약에 포함되지 않으며 프로덕션 워크로드에는 권장되지 않으며 일반적으로 사용 가능해지기 전에 변경되거나 제한될 수 있습니다. Azure AI 검색 미리 보기 용어는 독립 실행형 기능이든 일반 공급 기능의 일부이든 관계없이 모든 미리 보기 기능에 적용됩니다.
중요
이러한 기능과 기능은 다른 Microsoft 서비스 및 타사 서비스에 대한 연결을 지원합니다. 이러한 서비스의 사용은 해당 약관의 적용을 받으며 Azure 규정 준수 경계 외부의 데이터 처리 또는 스토리지뿐만 아니라 Azure 규정 준수 경계로 데이터가 유입될 수 있습니다.
데이터가 조직의 규정 준수 및 지리적 경계와 관련된 의미를 벗어나는지 여부와 적절한 권한, 경계 및 승인이 프로비전되는지를 관리하는 것은 사용자의 책임입니다.
특정 사용 사례의 컨텍스트에서 빌드한 애플리케이션을 신중하게 검토하고 테스트하고 모든 적절한 결정 및 사용자 지정을 수행할 책임이 있습니다. 여기에는 메타프롬프트, 콘텐츠 필터 또는 기타 안전 시스템과 같은 책임 있는 AI 완화를 구현하고 애플리케이션이 적절한 품질, 안정성, 보안 및 신뢰성 표준을 충족하도록 보장하는 것이 포함됩니다. 자세한 내용은 Azure AI 검색 투명성 정보를 참고하세요.
Azure Database for MySQL 인덱서(미리 보기)는 Azure Database for MySQL 유연한 서버의 콘텐츠를 Azure AI 검색 인덱스로 가져옵니다. 인덱서에 대한 입력은 단일 테이블 또는 뷰의 행입니다. 출력은 개별 필드에 검색 가능한 콘텐츠가 있는 검색 인덱스입니다.
이 문서에서는 인덱서 만들기 Azure Database for MySQL 유연한 서버의 인덱싱과 관련된 정보를 보완합니다. REST API를 사용하여 데이터 원본 만들기, 인덱스 만들기, 인덱서 만들기 등 모든 인덱서에 공통적인 세 부분으로 구성된 워크플로를 보여 줍니다. 데이터 추출은 인덱서 만들기 요청을 제출할 때 발생합니다.
상위 워터마크 및 일시 삭제를 포함하도록 구성되는 경우 인덱서는 MySQL 데이터베이스에 대한 모든 변경, 업로드 및 삭제를 수행합니다. 검색 인덱스의 이러한 변경 내용을 반영합니다. 데이터 추출은 인덱서 만들기 요청을 제출할 때 발생합니다.
필수 구성 요소
인덱서 미리 보기 등록 양식을 작성합니다. 등록이 자동으로 승인됩니다.
Azure Database for MySQL 유연한 서버 및 샘플 데이터입니다. 데이터는 테이블 또는 뷰에 있어야 합니다. 기본 키가 필요합니다. 보기를 사용하는 경우 높은 워터 마크 열이 있어야 합니다.
읽기 권한입니다. 전체 액세스 연결 문자열에는 콘텐츠에 대한 액세스 권한을 부여하는 키가 포함되어 있지만, Azure 역할을 사용하는 경우 검색 서비스 관리자 ID가 MySQL에 대한 Reader 권한이 있는지 확인해야 합니다.
데이터 원본, 인덱스 및 인덱서 만들기를 위한 REST 클라이언트 입니다.
Azure SDK for .NET을 사용할 수도 있습니다. 인덱서 만들기에는 Azure 포털을 사용할 수 없지만 인덱서 및 데이터 원본이 만들어지면 관리할 수 있습니다.
미리 보기 제한 사항
현재 날짜 또는 타임스탬프가 모든 행에 대해 균일한 경우 변경 내용 추적 및 삭제 검색이 작동하지 않습니다. 이 제한 사항은 미리 보기 업데이트에서 해결해야 하는 알려진 문제입니다. 이 문제가 해결될 때까지 MySQL 인덱서에 기술 세트를 추가하지 마세요.
미리 보기는 기하 도형 형식 및 Blob을 지원하지 않습니다.
앞에서 설명한 것처럼 인덱서 만들기에 대한 포털 지원은 없지만 MySQL 인덱서 및 데이터 원본이 있으면 Azure 포털에서 관리할 수 있습니다. 예를 들어 정의를 편집하고 인덱서 다시 설정, 실행 또는 예약을 수행할 수 있습니다.
데이터 원본 정의
데이터 원본 정의는 데이터의 변경 내용을 식별하기 위해 인덱싱할 데이터, 자격 증명 및 정책을 지정합니다. 데이터 원본은 여러 인덱서에서 사용할 수 있도록 독립적인 리소스로 정의됩니다.
데이터 원본 만들기 또는 업데이트 는 정의를 지정합니다. 데이터 원본을 만들 때 미리 보기 REST API를 사용해야 합니다.
{
"name" : "hotel-mysql-ds",
"description" : "[Description of MySQL data source]",
"type" : "mysql",
"credentials" : {
"connectionString" :
"Server=[MySQLServerName].MySQL.database.azure.com; Port=3306; Database=[DatabaseName]; Uid=[UserName]; Pwd=[Password]; SslMode=Preferred;"
},
"container" : {
"name" : "[TableName]"
},
"dataChangeDetectionPolicy" : {
"@odata.type": "#Microsoft.Azure.Search.HighWaterMarkChangeDetectionPolicy",
"highWaterMarkColumnName": "[HighWaterMarkColumn]"
}
}
핵심 사항:
type을"mysql"으로 설정합니다 (필수).credentials을 ADO.NET 연결 문자열로 설정합니다. Azure Portal의 Connection 문자열 페이지에서 MySQL에 대한 연결 문자열을 찾을 수 있습니다.테이블의 이름으로 설정합니다
container.데이터가 일시적이고 인덱서가 후속 실행 시 새 항목과 업데이트된 항목만 선택하도록 하려면 설정합니다
dataChangeDetectionPolicy.원본 항목이 삭제될 때 검색 인덱스에서 검색 문서를 제거하려면 설정합니다
dataDeletionDetectionPolicy.
참고
컨테이너 이름 속성의 경우 값은 문자, 숫자, 밑줄(_), 점(.), 단일 대시(-) 및 대괄호([])만 허용하도록 제한됩니다.
인덱스 만들기
인덱스 생성 또는 업데이트는 인덱스 스키마를 지정합니다.
{
"name" : "hotels-mysql-ix",
"fields": [
{ "name": "ID", "type": "Edm.String", "key": true, "searchable": false },
{ "name": "HotelName", "type": "Edm.String", "searchable": true, "filterable": false },
{ "name": "Category", "type": "Edm.String", "searchable": false, "filterable": true, "sortable": true },
{ "name": "City", "type": "Edm.String", "searchable": false, "filterable": true, "sortable": true },
{ "name": "Description", "type": "Edm.String", "searchable": false, "filterable": false, "sortable": false }
]
}
원본 테이블의 기본 키가 문서 키(이 경우 "ID")와 일치하는 경우 인덱서는 기본 키를 문서 키로 가져옵니다.
데이터 형식 매핑
다음 표는 MySQL 데이터베이스와 Azure AI 검색의 대응 항목을 매핑한 것입니다. 자세한 내용은 지원 데이터 형식(Azure AI 검색) 참조하세요.
참고
미리 보기는 기하 도형 형식 및 Blob을 지원하지 않습니다.
| MySQL 데이터 형식 | Azure AI 검색 필드 형식 |
|---|---|
bool, boolean |
Edm.Boolean, Edm.String |
tinyint, smallint, mediumint, int, integeryear |
Edm.Int32, Edm.Int64, Edm.String |
bigint |
Edm.Int64, Edm.String |
float, double, real |
Edm.Double, Edm.String |
date, datetime, timestamp |
Edm.DateTimeOffset, Edm.String |
char,varchar, tinytext, mediumtext, text, longtextenum, settime |
Edm.String |
| 부호 없는 숫자 데이터, 시리얼, 대수, 데크, 비트, 블롭, 이진, 기하학 | 해당 없음 |
MySQL 인덱서 구성 및 실행
인덱스 및 데이터 원본이 만들어지면 인덱서 만들 준비가 된 것입니다. 인덱서 구성은 런타임 동작을 제어하는 입력, 매개 변수 및 속성을 지정합니다.
인덱서에 이름을 지정하고 데이터 원본 및 대상 인덱스 참조를 사용하여 인덱서 만들기 또는 업데이트:
{
"name" : "hotels-mysql-idxr",
"dataSourceName" : "hotels-mysql-ds",
"targetIndexName" : "hotels-mysql-ix",
"disabled": null,
"schedule": null,
"parameters": {
"batchSize": null,
"maxFailedItems": null,
"maxFailedItemsPerBatch": null,
"base64EncodeKeys": null,
"configuration": { }
},
"fieldMappings" : [ ],
"encryptionKey": null
}
핵심 사항:
필드 이름 또는 형식에 차이가 있거나 검색 인덱스에 여러 버전의 원본 필드가 필요한 경우 필드 매핑을 지정합니다.
인덱서는 만들 때 자동으로 실행됩니다. 로 설정
disabledtrue하여 실행되지 않도록 할 수 있습니다. 인덱서 실행을 제어하려면 요청 시 인덱서를 실행하거나 일정에 따라 실행하십시오.
인덱서 상태 확인
인덱서 실행 모니터링을 위해 인덱서 상태 가져오기 요청을 보냅니다.
GET https://myservice.search.windows.net/indexers/myindexer/status?api-version=2026-08-01-preview
Content-Type: application/json
api-key: [admin key]
응답에는 상태 및 처리된 항목 수가 포함됩니다. 다음 예제와 유사하게 표시됩니다.
{
"status":"running",
"lastResult": {
"status":"success",
"errorMessage":null,
"startTime":"2024-02-21T00:23:24.957Z",
"endTime":"2024-02-21T00:36:47.752Z",
"errors":[],
"itemsProcessed":1599501,
"itemsFailed":0,
"initialTrackingState":null,
"finalTrackingState":null
},
"executionHistory":
[
{
"status":"success",
"errorMessage":null,
"startTime":"2024-02-21T00:23:24.957Z",
"endTime":"2024-02-21T00:36:47.752Z",
"errors":[],
"itemsProcessed":1599501,
"itemsFailed":0,
"initialTrackingState":null,
"finalTrackingState":null
},
... earlier history items
]
}
실행 기록에는 가장 최근에 완료된 실행 중 최대 50개까지 포함되며, 이 실행은 최신 실행이 먼저 수행되도록 역방향 시간순으로 정렬됩니다.
새 행 및 변경된 행 인덱싱
인덱서가 검색 인덱스를 완전히 채운 후에, 이후 실행되는 인덱서가 데이터베이스의 새 행과 변경된 행만 증분 인덱싱을 통해 인덱싱하도록 하고 싶을 수 있습니다.
증분 인덱싱을 사용하도록 설정하려면 데이터 원본 정의에서 속성을 설정합니다 dataChangeDetectionPolicy . 이 속성은 데이터에서 사용되는 변경 내용 추적 메커니즘을 인덱서에 알려줍니다.
Azure Database for MySQL 인덱서의 경우 유일하게 지원되는 정책은 HighWaterMarkChangeDetectionPolicy.
인덱서의 변경 검색 정책은 행 버전을 캡처하는 높은 워터 마크 열 또는 행이 마지막으로 업데이트된 날짜와 시간을 사용합니다. 상위 워터 마크 열에 대한 요구 사항을 충족하는 데 충분한 세분성의 DATE, DATETIME 또는 TIMESTAMP 열인 경우가 많습니다.
MySQL 데이터베이스에서 상위 워터 마크 열은 다음 요구 사항을 충족해야 합니다.
- 모든 데이터 삽입은 열의 값을 지정해야 합니다.
- 항목에 대한 모든 업데이트도 열 값을 변경합니다.
- 이 열의 값은 삽입 또는 업데이트할 때마다 증가합니다.
- 다음
WHERE및ORDER BY절이 있는 쿼리를 효율적으로 실행할 수 있습니다.WHERE [High Water Mark Column] > [Current High Water Mark Value] ORDER BY [High Water Mark Column]
다음 예제에서는 변경 검색 정책이 있는 데이터 원본 정의를 보여줍니다.
{
"name" : "[Data source name]",
"type" : "mysql",
"credentials" : { "connectionString" : "[connection string]" },
"container" : { "name" : "[table or view name]" },
"dataChangeDetectionPolicy" : {
"@odata.type" : "#Microsoft.Azure.Search.HighWaterMarkChangeDetectionPolicy",
"highWaterMarkColumnName" : "[last_updated column name]"
}
}
중요
뷰를 사용하는 경우 인덱서 데이터 원본에 하이 워터마크 정책을 설정해야 합니다.
원본 테이블에 상위 워터 마크 열에 인덱스가 없는 경우 MySQL 인덱서에서 사용하는 쿼리는 시간이 초과될 수 있습니다. 특히 테이블에 많은 행이 포함된 경우, ORDER BY [High Water Mark Column] 절은 인덱스를 사용해 효율적으로 실행할 수 있어야 합니다.
삭제된 행 인덱싱
테이블 또는 뷰에서 행을 삭제하는 경우 일반적으로 검색 인덱스에서도 해당 행을 삭제하려고 합니다. 그러나 행이 테이블에서 물리적으로 제거되는 경우 인덱서는 더 이상 존재하지 않는 레코드의 존재를 유추할 방법이 없습니다. 해결 방법은 일시 삭제 기술을 사용하여 행을 테이블에서 제거하지 않고 논리적으로 삭제하는 것입니다. 테이블 또는 뷰에 열을 추가하고 해당 열을 사용하여 행을 삭제된 것으로 표시합니다.
삭제 상태를 제공하는 열이 지정된 경우 삭제 상태가 설정된 true검색 문서를 모두 제거하도록 인덱서를 구성할 수 있습니다. 이 동작을 지원하는 구성 속성은 다음과 같이 데이터 원본 정의 에 지정된 데이터 삭제 검색 정책입니다.
{
…,
"dataDeletionDetectionPolicy" : {
"@odata.type" : "#Microsoft.Azure.Search.SoftDeleteColumnDeletionDetectionPolicy",
"softDeleteColumnName" : "[a column name]",
"softDeleteMarkerValue" : "[the value that indicates that a row is deleted]"
}
}
softDeleteMarkerValue 문자열이어야 합니다. 예를 들어 삭제된 행이 값 1로 표시된 정수 열이 있는 경우 "1"를 사용하세요. 삭제된 행이 부울 true 값으로 표시된 BIT 열이 있는 경우 True 또는 true 문자열 리터럴(대/소문자 구분 안 함)을 사용합니다.
다음 단계
이제 인덱서 실행, 상태 모니터링 또는 인덱서 실행을 예약할 수 있습니다. 다음 문서는 Azure MySQL에서 콘텐츠를 끌어오는 인덱서에 적용됩니다.