Indexação de dados do Banco de Dados do Azure para MySQL Flexible Server (versão prévia)

O indexador do Banco de Dados do Azure para MySQL (versão prévia) importa conteúdo do Banco de Dados do Azure para MySQL Servidor Flexível para um índice do Pesquisa de IA do Azure . As entradas para o indexador são linhas de uma única tabela ou exibição. A saída é um índice de pesquisa com conteúdo pesquisável em campos individuais.

Este artigo complementa Criar um indexador com informações que são específicas para indexação do Servidor Flexível do Banco de Dados do Azure para MySQL. Ele usa as APIs REST para demonstrar um fluxo de trabalho de três partes comum a todos os indexadores: criar uma fonte de dados, criar um índice e criar um indexador. A extração de dados ocorre quando você envia a solicitação Criar Indexador.

Quando configurado para incluir a marca-d'água alta e a exclusão reversível, o indexador realiza todas as alterações, uploads e exclusões do seu banco de dados MySQL. Isso reflete essas alterações no índice de pesquisa. A extração de dados ocorre quando você envia a solicitação Criar Indexador.

Pré-requisitos

• Preencha o formulário de registro de visualização do indexador. O registro é aprovado automaticamente.

• Servidor Flexível do Banco de Dados do Azure para MySQL e dados de exemplo. Os dados devem residir em uma tabela ou exibição. Uma chave primária é necessária. Se você estiver usando uma exibição, ela precisará ter uma coluna de marca-d'água alta.

• Permissões de leitura. Uma string de conexão completa inclui uma chave que concede acesso ao conteúdo, mas se você estiver usando funções do Azure, verifique se a identidade gerenciada do serviço de pesquisa tem permissões de Leitor no MySQL.

• Um cliente REST para criar a fonte de dados, o índice e o indexador.

  Você também pode usar o SDK do Azure para .NET. Você não pode usar o portal Azure para a criação do indexador, mas pode gerenciar indexadores e fontes de dados depois que eles são criados.

Limitações de pré-visualização

No momento, o controle de alterações e a detecção de exclusão não estão funcionando se a data ou o carimbo de data/hora é igual em todas as linhas. Essa limitação é um problema conhecido a ser resolvido em uma atualização para a versão prévia. Até que esse problema seja resolvido, não adicione um conjunto de habilidades ao indexador MySQL.

A versão prévia não dá suporte a tipos de geometria e blobs.

Como observado, não há suporte do portal para a criação do indexador, mas um indexador MySQL e uma fonte de dados podem ser gerenciados no portal Azure quando eles existirem. Por exemplo, você pode editar as definições e redefinir, executar ou agendar o indexador.

Definir a fonte de dados

A definição da fonte de dados especifica os dados para indexar, credenciais e políticas para identificar alterações nos dados. A fonte de dados é definida como um recurso independente para que possa ser usada por vários indexadores.

Criar ou atualizar a fonte de dados especifica a definição. Use uma API REST de visualização ao criar a fonte de dados.

{   
    "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]"
    }
}

Pontos-chave:

• Definido type como "mysql" (obrigatório).

• Defina credentials como uma cadeia de conexão ADO.NET. Você pode encontrar strings de conexão no portal Azure, na página Cadeias de Conexão do MySQL.

• Defina container como o nome da tabela.

• Defina dataChangeDetectionPolicy se os dados são voláteis e você deseja que o indexador pegue apenas os itens novos e atualizados nas execuções subsequentes.

• Defina dataDeletionDetectionPolicy se quiser remover documentos de pesquisa de um índice de pesquisa quando o item de origem for excluído.

Criar um índice

Criar ou atualizar índice especifica o esquema de índice:

{
    "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  }     
    ]
}

Se a chave primária na tabela de origem corresponder à chave do documento (nesse caso, "ID"), o indexador importará a chave primária como a chave do documento.

Mapeamento de tipos de dados

A tabela a seguir mapeia o banco de dados MySQL para os equivalentes do Pesquisa de IA do Azure . Para obter mais informações, consulte Tipos de dados suportados (Pesquisa de IA do Azure ).

Configurar e executar o indexador MySQL

Depois que o índice e a fonte de dados tiverem sido criados, você estará pronto para criar o indexador. A configuração do indexador especifica as entradas, os parâmetros e as propriedades que controlam os comportamentos de tempo de execução.

Crie ou atualize um indexador dando-lhe um nome e fazendo referência à fonte de dados e ao índice de destino:

{
    "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
}

Pontos-chave:

• Especifique mapeamentos de campo se houver diferenças no nome ou tipo de campo ou se você precisar de várias versões de um campo de origem no índice de pesquisa.

• Um indexador é executado automaticamente quando é criado. Você pode impedir que ele seja executado definindo disabled como true. Para controlar a execução do indexador, execute um indexador sob demanda ou coloque-o em um agendamento.

Verificar o status do indexador

Envie uma solicitação Obter Status do Indexador para monitorar a execução do indexador:

GET https://myservice.search.windows.net/indexers/myindexer/status?api-version=2026-08-01-preview
  Content-Type: application/json  
  api-key: [admin key]

A resposta inclui o status e o número de itens processados. Ele deve ser semelhante ao exemplo a seguir:

{
    "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
    ]
}

O histórico de execução contém até 50 das execuções concluídas mais recentemente, que são classificadas na ordem cronológica inversa para que a execução mais recente venha primeiro.

Indexando linhas novas e alteradas

Depois que um indexador tiver preenchido totalmente um índice de pesquisa, talvez você queira que o indexador subsequente seja executado para indexar incrementalmente apenas as linhas novas e alteradas em seu banco de dados.

Para habilitar a indexação incremental, defina a dataChangeDetectionPolicy propriedade em sua definição de fonte de dados. Essa propriedade informa ao indexador qual mecanismo de controle de alterações é usado em seus dados.

Para Banco de Dados do Azure para MySQL indexadores, a única política com suporte é a HighWaterMarkChangeDetectionPolicy.

A política de detecção de alterações de um indexador depende de ter uma coluna de marcador de referência que captura a versão da linha ou a data e hora em que uma linha foi atualizada pela última vez. Muitas vezes, é uma coluna DATE, DATETIME ou TIMESTAMP com granularidade suficiente para atender aos requisitos de uma coluna de marca d'água alta.

No banco de dados MySQL, a coluna de marca d'água alta precisa atender aos seguintes requisitos:

• Todas as inserções de dados devem especificar um valor para a coluna.
• Todas as atualizações para um item também alteram o valor da coluna.
• O valor dessa coluna aumenta a cada inserção ou atualização.
• Consultas com o seguinte WHERE e ORDER BY cláusulas podem ser executadas com eficiência: WHERE [High Water Mark Column] > [Current High Water Mark Value] ORDER BY [High Water Mark Column]

O exemplo a seguir mostra uma definição de fonte de dados com uma política de detecção de alterações:

{
    "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]"
    }
}

Indexando linhas excluídas

Quando as linhas são excluídas da tabela ou exibição, normalmente, você também deseja excluir essas linhas do índice de pesquisa. No entanto, se as linhas forem removidas fisicamente da tabela, um indexador não terá como inferir a presença de registros que não existem mais. A solução é usar uma técnica soft-delete para excluir logicamente as linhas sem removê-las da tabela. Adicione uma coluna à sua tabela ou exibição e marque linhas como excluídas usando essa coluna.

Dada uma coluna que fornece o estado de exclusão, um indexador pode ser configurado para remover todos os documentos de pesquisa para os quais o estado de exclusão está definido como true. A propriedade de configuração que dá suporte a esse comportamento é uma política de detecção de exclusão de dados, que é especificada na definição da fonte de dados da seguinte maneira:

{
    …,
    "dataDeletionDetectionPolicy" : {
        "@odata.type" : "#Microsoft.Azure.Search.SoftDeleteColumnDeletionDetectionPolicy",
        "softDeleteColumnName" : "[a column name]",
        "softDeleteMarkerValue" : "[the value that indicates that a row is deleted]"
    }
}

Deve softDeleteMarkerValue ser uma cadeia de caracteres. Por exemplo, se você tiver uma coluna de inteiro em que as linhas excluídas são marcadas com o valor 1, use "1". Se você tiver uma coluna BIT onde as linhas excluídas são marcadas com o valor booleano 'true', use o literal de cadeia de caracteres True ou true (o caso não importa).

Próximas etapas

Agora você pode executar o indexador, monitorar o status ou agendar a execução do indexador. Os artigos a seguir se aplicam aos indexadores que extraem conteúdo do Azure MySQL:

• Indexar conjuntos de dados grandes
• Acesso do Indexador ao conteúdo protegido pelos recursos de segurança de rede do Azure