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

Из этой статьи вы узнаете, как настроить индексатор, который импортирует содержимое из База данных 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).

Настройка и запуск индексатора 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только политика.

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

В базе данных 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]"
    }
}

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

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

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

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