Indexar datos de Azure Database for MySQL Flexible Server (versión preliminar)

El indexador de Azure Database for MySQL (versión preliminar) importa contenido desde el servidor flexible de Azure Database for MySQL en un índice de Búsqueda de Azure AI. Las entradas del indexador son filas de una sola tabla o vista. La salida es un índice de búsqueda con contenido que se puede buscar en campos individuales.

Este artículo complementa Crear un indexador con información específica de la indexación desde el servidor flexible de Azure Database para MySQL. Usa las API REST para mostrar un flujo de trabajo de tres partes común a todos los indexadores: crear un origen de datos, crear un índice y crear un indexador. La extracción de datos se produce al enviar la solicitud Crear indexador.

Si se configura para incluir un límite máximo y eliminación temporal, el indexador realiza todos los cambios, las cargas y las eliminaciones de la base de datos MySQL. Refleja estos cambios en el índice de búsqueda. La extracción de datos se produce al enviar la solicitud Crear indexador.

Requisitos previos

• Complete el formulario de registro de vista previa del indexador. El registro se aprueba automáticamente.

• Servidor flexible de Azure Database for MySQL y datos de ejemplo. Los datos deben residir en una tabla o vista. Se requiere una clave principal. Si usa una vista, debe tener una columna de límite máximo.

• Permisos de lectura. Una cadena de conexión de acceso completo incluye una clave que concede acceso al contenido, pero si usa roles de Azure, asegúrese de que la identidad administrada del servicio de búsqueda search tiene permisos de Lector en MySQL.

• Un cliente REST para crear el origen de datos, el índice y el indexador.

  También puede usar el SDK de Azure para .NET. No puede usar el portal de Azure para la creación del indexador, pero puede administrar indexadores y orígenes de datos una vez creados.

Limitaciones de la versión preliminar

Actualmente, el seguimiento de cambios y la detección de eliminación no funcionan si la fecha o marca de tiempo es uniforme para todas las filas. Esta limitación es un problema conocido que se debe solucionar en una actualización de la versión preliminar. Hasta que se solucione este problema, no agregue un conjunto de aptitudes al indexador de MySQL.

La versión preliminar no admite tipos de geometría ni blobs.

Como se indicó, no hay compatibilidad con el portal para la creación del indexador, pero se puede administrar un indexador y un origen de datos mySQL en el portal de Azure una vez que existen. Por ejemplo, puede editar las definiciones y restablecer, ejecutar o programar el indexador.

Definición del origen de datos

La definición del origen de datos especifica los datos que se van a indexar, las credenciales y las directivas para identificar los cambios en los datos. El origen de datos se define como un recurso independiente para que varios indexadores puedan usarlos.

Crear o actualizar origen de datos define la especificación. Asegúrese de usar una API REST en versión preliminar al crear el origen de datos.

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

Puntos clave:

• Establézcalo type en "mysql" (obligatorio).

• Establezca credentials en un ADO.NET cadena de conexión. Puede encontrar cadenas de conexión en Azure portal, en la página Connection strings para MySQL.

• Establezca container en el nombre de la tabla.

• Establezca dataChangeDetectionPolicy si los datos son volátiles y desea que el indexador seleccione solo los elementos nuevos y actualizados en ejecuciones posteriores.

• Establezca dataDeletionDetectionPolicy si desea quitar documentos de búsqueda de un índice de búsqueda cuando se elimina el elemento de origen.

Creación de un índice

Crear o actualizar índice especifica el 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  }     
    ]
}

Si la clave principal de la tabla de origen coincide con la clave de documento (en este caso, "ID"), el indexador importa la clave principal como clave de documento.

Mapeo de tipos de datos

En la siguiente tabla se asigna la base de datos MySQL a su equivalente en Búsqueda de Azure AI. Para obtener más información, vea Supported data types (Búsqueda de Azure AI).

Configuración y ejecución del indexador de MySQL

Una vez creado el índice y el origen de datos, está listo para crear el indexador. La configuración del indexador especifica las entradas, los parámetros y las propiedades que controlan los comportamientos de tiempo de ejecución.

Cree o actualice un indexador ; para ello, asígnele un nombre y haga referencia al origen de datos y al í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
}

Puntos clave:

• Especifique las asignaciones de campos si hay diferencias en el nombre o el tipo de campo, o si necesita varias versiones de un campo de origen en el índice de búsqueda.

• Un indexador se ejecuta automáticamente cuando se crea. Puede impedir que se ejecute configurando disabled en true. Para controlar la ejecución del indexador, ejecute un indexador a petición o colóquelo según una programación.

Comprobación del estado del indexador

Envíe una solicitud Get Indexer Status para supervisar la ejecución del indexador:

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

La respuesta incluye el estado y el número de elementos procesados. Debería ser similar al ejemplo siguiente:

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

El historial de ejecución contiene hasta 50 de las ejecuciones completadas más recientemente, que se ordenan en el orden cronológico inverso para que la ejecución más reciente llegue primero.

Indexación de filas nuevas y modificadas

Una vez que un indexador haya rellenado completamente un índice de búsqueda, es posible que desee que el indexador posterior se ejecute incrementalmente para indexar solo las filas nuevas y modificadas de la base de datos.

Para habilitar la indexación incremental, establezca la propiedad en la dataChangeDetectionPolicy definición del origen de datos. Esta propiedad indica al indexador qué mecanismo de seguimiento de cambios se usa en los datos.

Para los indexadores de Azure Database for MySQL, la única directiva admitida es la HighWaterMarkChangeDetectionPolicy.

La directiva de detección de cambios de un indexador se basa en tener una columna de límite máximo que capture la versión de fila o la fecha y hora en que se actualizó por última vez una fila. Suele ser una columna DATE, DATETIME o TIMESTAMP con una granularidad suficiente para cumplir los requisitos de una columna de límite máximo.

En la base de datos de MySQL, la columna de límite máximo debe cumplir los siguientes requisitos:

• Todas las inserciones de datos deben especificar un valor para la columna.
• Todas las actualizaciones de un elemento también cambian el valor de la columna.
• El valor de esta columna aumenta con cada inserción o actualización.
• Las consultas con las siguientes cláusulas WHERE y ORDER BY se pueden ejecutar de forma eficaz: WHERE [High Water Mark Column] > [Current High Water Mark Value] ORDER BY [High Water Mark Column]

En el ejemplo siguiente se muestra una definición de origen de datos con una directiva de detección de cambios:

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

Indexación de filas eliminadas

Cuando las filas se eliminan de la tabla o vista, normalmente también desea eliminar esas filas del índice de búsqueda. Sin embargo, si las filas se quitan físicamente de la tabla, un indexador no tiene forma de deducir la presencia de registros que ya no existen. La solución pasa por usar una técnica de eliminación temporal para eliminar filas de forma lógica sin quitarlas de la tabla. Agregue una columna a la tabla o vista y marque las filas como eliminadas mediante esa columna.

Dada una columna que proporciona el estado de eliminación, se puede configurar un indexador para quitar los documentos de búsqueda para los que el estado de eliminación se establece en true. La propiedad de configuración que admite este comportamiento es una directiva de detección de eliminación de datos, que se especifica en la definición del origen de datos de la siguiente manera:

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

softDeleteMarkerValue debe ser una cadena. Por ejemplo, si tiene una columna entera donde las filas eliminadas se marcan con el valor 1, use "1". Si tiene una BIT columna donde las filas eliminadas están marcadas con el valor booleano `true`, use el literal de cadena True o true (el caso no importa).

Pasos siguientes

Ahora puede ejecutar el indexador, supervisar el estado o programar la ejecución del indexador. Los artículos siguientes se aplican a los indexadores que extraen contenido de Azure MySQL:

• Indexación de grandes conjuntos de datos
• Acceso del indexador al contenido protegido por las características de seguridad de red de Azure.