Индексирование данных из гибкого сервера База данных Azure для MySQL (предварительная версия)

Индексатор База данных Azure для MySQL (предварительная версия) импортирует содержимое из гибкого сервера База данных Azure для MySQL в индекс Поиск с использованием ИИ Azure. Входные данные индексатора — это строки из одной таблицы или представления. Выходные данные — это индекс поиска с искомым содержимым в отдельных полях.

Эта статья дополняет Создать индексатор сведениями, специфическими для индексации из База данных Azure для MySQL Flexible Server. В нем используются ИНТЕРФЕЙСы REST API для демонстрации трех частей рабочего процесса, общего для всех индексаторов: создание источника данных, создание индекса, создание индексатора. Извлечение данных происходит при отправке запроса create Indexer.

При настройке включения отметки высокого уровня и мягкого удаления индексатор принимает все изменения, загружает и удаляет данные в вашей базе данных MySQL. Он отражает эти изменения в индексе поиска. Извлечение данных происходит при отправке запроса create Indexer.

Необходимые условия

• Заполните форму регистрации индексатора предварительной версии. Регистрация автоматически утверждена.

• База данных Azure для MySQL Flexible Server и примерные данные. Данные должны находиться в таблице или представлении. Требуется первичный ключ. Если вы используете представление, оно должно иметь столбец с отметкой высокого уровня.

• Разрешения на чтение. Строка подключения с полным доступом включает ключ, который предоставляет доступ к содержимому, но если вы используете роли Azure, убедитесь, что у управляемого удостоверения поисковой службы есть разрешения Reader на MySQL.

• Клиент REST для создания источника данных, индекса и индексатора.

  Можно также использовать Azure SDK для .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 на странице Connection strings для 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. Дополнительные сведения см. в разделе Supported data types (Поиск с использованием ИИ Azure).

Настройка и запуск индексатора 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 Indexer Status, чтобы отслеживать выполнение индексатора:

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 для MySQL только поддерживаемая политика — это HighWaterMarkChangeDetectionPolicy.

Политика обнаружения изменений индексатора полагается на столбец с высокой отметкой, фиксирующий версию строки или дату и время ее последнего обновления. Это часто столбец DATE, DATETIME или TIMESTAMP с уровнем детализации, достаточным для выполнения требований столбца с контрольными отметками уровня.

В вашей базе данных MySQL столбец максимальной отметки должен соответствовать следующим требованиям:

• Все вставки данных должны указывать значение для столбца.
• Все обновления элемента также изменяют значение столбца.
• Значение этого столбца увеличивается при каждой вставке или обновлении.
• Запросы со следующими WHEREORDER 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]"
    }
}

Индексирование удаленных строк

При удалении строк из таблицы или представления обычно требуется удалить эти строки из индекса поиска. Однако если строки физически удаляются из таблицы, индексатор не может определить наличие записей, которые больше не существуют. Решение заключается в использовании метода мягкого удаления для логического удаления строк без их физического удаления из таблицы. Добавьте столбец в таблицу или представление и пометьте строки как удаленные с помощью этого столбца.

Учитывая столбец, предоставляющий состояние удаления, индексатор можно настроить для удаления всех документов поиска, для которых задано 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:

• Индексирование больших наборов данных
• доступ Indexer к содержимому, защищенному функциями безопасности сети Azure