Индексирование данных с гибкого сервера База данных Azure для MySQL
Внимание
Поддержка MySQL сейчас предоставляется в общедоступной предварительной версии, и для нее действуют дополнительные условия использования. Для индексирования содержимого можно использовать 2020-06-30-preview или более поздней версии. Рекомендуется использовать последнюю предварительную версию API. В настоящее время поддержка портала отсутствует.
Из этой статьи вы узнаете, как настроить индексатор, который импортирует содержимое из База данных Azure для MySQL и делает его доступным для поиска в службе "Поиск искусственного интеллекта Azure". Входные данные индексатора — это строка в одной таблице или представлении. Выходные данные — это индекс поиска с искомым содержимым в отдельных полях.
В этой статье описано, как создать индексатор со сведениями, которые относятся к индексации с База данных Azure для MySQL гибкого сервера. В нем используются ИНТЕРФЕЙСы REST API для демонстрации трех частей рабочего процесса, общего для всех индексаторов: создание источника данных, создание индекса, создание индексатора. Извлечение данных происходит при отправке запроса create Indexer.
При настройке включения высокой водяной метки и обратимого удаления индексатор принимает все изменения, отправляет и удаляет базу данных MySQL. Он отражает эти изменения в индексе поиска. Извлечение данных происходит при отправке запроса create Indexer.
Необходимые компоненты
Зарегистрируйтесь для предварительной версии , чтобы предоставить отзыв о сценарии. После отправки формы вы можете автоматически получить доступ к функции.
База данных Azure для MySQL гибкий сервер и примеры данных. Данные должны находиться в таблице или представлении. Требуется первичный ключ. Если вы используете представление, он должен иметь столбец с высокой водой.
Разрешения на чтение. Полный доступ строка подключения включает ключ, который предоставляет доступ к содержимому, но если вы используете роли Azure, убедитесь, что управляемое удостоверение службы поиска имеет разрешения читателя в MySQL.
Клиент REST для создания источника данных, индекса и индексатора.
Вы также можете использовать пакет SDK Azure для .NET. Вы не можете использовать портал для создания индексатора, но вы можете управлять индексаторами и источниками данных после их создания.
Ограничения предварительной версии
В настоящее время обнаружение отслеживания изменений и удаления не работает, если метка даты или времени является единообразной для всех строк. Это ограничение является известной проблемой, устраняемой в обновлении предварительной версии. Пока эта проблема не будет устранена, не добавляйте набор навыков в индексатор MySQL.
Предварительная версия не поддерживает геометрические типы и большие двоичные объекты.
Как отмечалось, на портале нет поддержки создания индексатора, но индексатор MySQL и источник данных можно управлять на портале после их существования. Например, можно изменить определения и сбросить, запустить или запланировать индексатор.
Определение источника данных
Определение источника данных указывает данные для индексирования, учетных данных и политик для выявления изменений в данных. Источник данных определяется как независимый ресурс, который может использоваться несколькими индексаторами.
Создание или обновление источника данных указывает определение. При создании источника данных обязательно используйте 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 на странице строк подключения для 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. Дополнительные сведения см. в разделе "Поддерживаемые типы данных" (поиск ИИ Azure).
Примечание.
Эта предварительная версия не поддерживает геометрические типы и BLOB-объекты.
Типы данных MySQL | Типы полей поиска ИИ Azure |
---|---|
bool , boolean |
Edm.Boolean, Edm.String |
tinyint , , smallint int mediumint integer ,year |
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 longtext enum set time |
Edm.String |
числовые данные без знака, serial, decimal, dec, bit, blob, binary, geometry | Н/П |
Настройка и запуск индексатора 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
}
Основные моменты:
Укажите сопоставления полей, если существуют различия в имени или типе поля, или если в индексе поиска требуется несколько версий исходного поля.
Индексатор запускается автоматически при его создании. Его можно запретить, установив для него значение
disabled
true
. Чтобы управлять выполнением индексатора, запустите индексатор по запросу или поместите его в расписание.
Проверка состояния индексатора
Отправьте запрос состояния индексатора для отслеживания выполнения индексатора:
GET https://myservice.search.windows.net/indexers/myindexer/status?api-version=2024-05-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 для 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"
. Если у вас есть BIT
столбец, в котором удаленные строки помечены логическим значением true, используйте строковый литерал True
или true
(дело не имеет значения).
Следующие шаги
Теперь можно запустить индексатор, состояние монитора или запланировать выполнение индексатора. Следующие статьи относятся к индексаторам, которые извлекает содержимое из Azure MySQL: