Indexar dados de Base de Dados do Azure para MySQL Flexible Server (pré-visualização)

O indexador Base de Dados do Azure para MySQL (pré-visualização) importa conteúdos do Base de Dados do Azure para MySQL Flexible Server para um índice Pesquisa de IA do Azure. As entradas para o indexador são linhas de uma única tabela ou visão. Output é um índice de pesquisa com conteúdo pesquisável em campos individuais.

Este artigo complementa Criar um indexador com informações específicas para indexação a partir de Azure Database para MySQL Servidor Flexível. Utiliza as APIs REST para demonstrar um fluxo de trabalho em três partes comum a todos os indexadores: criar uma fonte de dados, criar um índice, criar um indexador. A extração de dados ocorre quando submete o pedido Create Indexer.

Quando configurado para incluir um limite máximo e uma eliminação temporária, o indexador processa todas as alterações, carregamentos e eliminações na sua base de dados MySQL. Reflete estas alterações no seu índice de pesquisa. A extração de dados ocorre quando submete o pedido Create Indexer.

Pré-requisitos

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

• Base de Dados do Azure para MySQL - Servidor Flexível e dados de exemplo. Os dados devem residir numa tabela ou visualização. É necessária uma chave primária. Se estiver a usar uma vista, ela deve ter uma coluna de marca d'água alta.

• Ler permissões. Um full access cadeia de ligação inclui uma chave que concede acesso ao conteúdo, mas se você estiver a usar funções do Azure, certifique-se de que a identidade gerida do serviço de pesquisa possui permissões de Leitor no MySQL.

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

  Também podes usar o SDK do Azure para .NET. Não pode usar o portal do Azure para criação de indexadores, mas pode gerir indexadores e fontes de dados depois de criados.

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

Atualmente, o rastreio de alterações e a deteção de eliminação não funcionam se a data ou hora for uniforme para todas as linhas. Esta limitação é um problema conhecido a ser abordado numa atualização da pré-visualização. Até que este problema seja resolvido, não adicione um conjunto de competências ao indexador MySQL.

A pré-visualização não suporta tipos de geometria nem blobs.

Como referido, não há suporte de portal para criação de indexadores, mas um indexador MySQL e uma fonte de dados podem ser geridos no portal do Azure assim que existirem. Por exemplo, pode editar as definições e reiniciar, executar ou agendar o indexador.

Defina a fonte de dados

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

Criar ou Atualizar Fonte de Dados especifica a definição. Certifique-se de usar uma API REST de pré-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:

• Definir type para "mysql" (obrigatório).

• Defina credentials como uma cadeia de ligação ADO.NET. Podes encontrar cadeias de ligação no portal Azure, na página Connection strings para MySQL.

• Defina container para o nome da tabela.

• Define dataChangeDetectionPolicy se os dados estiverem voláteis e queres que o indexador apanhe apenas os itens novos e atualizados nas execuções seguintes.

• Define dataDeletionDetectionPolicy se quiseres remover documentos de pesquisa de um índice de pesquisa quando o item de origem for eliminado.

Criar um índice

O Índice Criar ou Atualizar especifica o esquema do í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 (neste caso, "ID"), o indexador importa a chave primária como chave do documento.

Mapeamento dos tipos de dados

A tabela seguinte mapeia a base de dados MySQL para equivalentes ao Pesquisa de IA do Azure. Para mais informações, consulte Tipos de dados suportados (Pesquisa de IA do Azure).

Configure e execute o indexador MySQL

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

Crie ou atualize um indexador atribuindo-lhe um nome e referenciando a fonte de dados e o índice alvo:

{
    "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 campos se existirem diferenças no nome ou tipo do campo, ou se precisar de múltiplas versões de um campo de origem no índice de pesquisa.

• Um indexador corre automaticamente quando é criado. Pode impedir que funcione definindo disabled para true. Para controlar a execução do indexador, execute um indexador a pedido ou coloque-o num calendário.

Verificar o estado do indexador

Envie um pedido de Estado do Indexador para monitorizar 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 estado e o número de itens processados. Deverá assemelhar-se ao seguinte exemplo:

{
    "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ções contém até 50 das execuções mais recentemente concluídas, que estão ordenadas por ordem cronológica inversa para que a execução mais recente venha primeiro.

Indexação de linhas novas e alteradas

Depois de um indexador preencher totalmente um índice de pesquisa, pode querer que as execuções subsequentes indexem incrementalmente apenas as linhas novas e alteradas na sua base de dados.

Para permitir a indexação incremental, defina a dataChangeDetectionPolicy propriedade na definição da sua fonte de dados. Esta propriedade indica ao indexador qual o mecanismo de acompanhamento de alterações utilizado nos seus dados.

Para Base de Dados do Azure para MySQL indexadores, a única política suportada é a HighWaterMarkChangeDetectionPolicy.

A política de deteção de alterações de um indexador baseia-se em ter uma coluna de marca alta que capture a versão da linha, ou seja, a data e hora em que uma linha foi atualizada pela última vez. É frequentemente uma coluna DATE, DATETIME ou TIMESTAMP com uma granularidade suficiente para cumprir os requisitos de uma coluna com alto nível de referência.

Na sua base de dados MySQL, a coluna de marca alta deve cumprir os seguintes requisitos:

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

O exemplo seguinte mostra uma definição de fonte de dados com uma política de deteçã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]"
    }
}

Indexação de linhas eliminadas

Quando as linhas são eliminadas da tabela ou da vista, normalmente queres apagar essas linhas do índice de pesquisa também. No entanto, se as linhas forem fisicamente removidas da tabela, um indexador não tem forma de inferir a presença de registos que já não existem. A solução é usar uma técnica de soft delete para apagar logicamente linhas sem as remover da tabela. Adiciona uma coluna à tua tabela ou visualização e marca as linhas como eliminadas usando essa coluna.

Dada uma coluna que fornece o estado de eliminação, um indexador pode ser configurado para remover quaisquer documentos de pesquisa cujo estado de eliminação esteja definido para true. A propriedade de configuração que suporta este comportamento é uma política de deteção de eliminação de dados, especificada na definição da fonte de dados da seguinte forma:

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

Deve softDeleteMarkerValue ser um fio. Por exemplo, se tiver uma coluna de inteiros onde as linhas eliminadas são marcadas com o valor 1, use "1". Se tiver uma BIT coluna onde as linhas eliminadas são marcadas com o valor booleano verdadeiro, use o literal de cadeia de caracteres True ou true (o caso não importa).

Próximos passos

Agora pode executar o indexador, monitorizar o estado ou agendar a execução do indexador. Os seguintes artigos aplicam-se a indexadores que extraem conteúdo do Azure MySQL:

• Indexar conjuntos de dados grandes
• Acesso do indexador a conteúdos protegidos pelas funcionalidades de segurança de rede da Azure