Indexera data från Azure Database for MySQL – flexibel server

Artikel
03/11/2024

Viktigt!

MySQL-stöd finns för närvarande i offentlig förhandsversion under kompletterande användningsvillkor. Använd ett REST API för förhandsversion (2020-06-30-preview eller senare) för att indexera ditt innehåll. Det finns för närvarande inget portalstöd.

I den här artikeln får du lära dig hur du konfigurerar en indexerare som importerar innehåll från Azure Database for MySQL och gör det sökbart i Azure AI Search. Indata till indexeraren är din rad, i en enda tabell eller vy. Utdata är ett sökindex med sökbart innehåll i enskilda fält.

Den här artikeln kompletterar Skapa en indexerare med information som är specifik för indexering från en flexibel Azure Database for MySQL-server. Den använder REST-API:er för att demonstrera ett arbetsflöde i tre delar som är gemensamt för alla indexerare: skapa en datakälla, skapa ett index, skapa en indexerare. Dataextrahering sker när du skickar begäran skapa indexerare.

När indexeraren har konfigurerats för att inkludera ett högvattenmärke och mjuk borttagning tar den alla ändringar, uppladdningar och borttagningar för mySQL-databasen. Den återspeglar dessa ändringar i ditt sökindex. Dataextrahering sker när du skickar begäran skapa indexerare.

Förutsättningar

Registrera dig för förhandsversionen för att ge feedback om scenariot. Du kan komma åt funktionen automatiskt efter att formuläret har lämnats in.
Azure Database for MySQL – flexibel server och exempeldata. Data måste finnas i en tabell eller vy. En primärnyckel krävs. Om du använder en vy måste den ha en högvattenmärkeskolumn.
Läsbehörigheter. En fullständig åtkomst anslutningssträng innehåller en nyckel som ger åtkomst till innehållet, men om du använder Azure-roller kontrollerar du att söktjänstens hanterade identitet har läsbehörighet på MySQL.
En REST-klient för att skapa datakällan, indexet och indexeraren.

Du kan också använda Azure SDK för .NET. Du kan inte använda portalen för att skapa indexerare, men du kan hantera indexerare och datakällor när de har skapats.

Begränsningar i förhandsversionen

För närvarande fungerar inte identifiering av ändringsspårning och borttagning om datum- eller tidsstämpeln är enhetlig för alla rader. Den här begränsningen är ett känt problem som ska åtgärdas i en uppdatering av förhandsversionen. Lägg inte till en kompetensuppsättning till MySQL-indexeraren förrän det här problemet har åtgärdats.

Förhandsversionen stöder inte geometrityper och blobar.

Som nämnts finns det inget portalstöd för att skapa indexerare, men en MySQL-indexerare och datakälla kan hanteras i portalen när de finns. Du kan till exempel redigera definitionerna och återställa, köra eller schemalägga indexeraren.

Definiera datakällan

Datakällans definition anger vilka data som ska indexeras, autentiseringsuppgifter och principer för att identifiera ändringar i data. Datakällan definieras som en oberoende resurs så att den kan användas av flera indexerare.

Skapa eller uppdatera datakälla anger definitionen. Se till att använda en REST API-förhandsversion (2020-06-30-Preview eller senare) när du skapar datakällan.

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

Viktiga punkter:

Ange type till "mysql" (krävs).
Ange credentials till en ADO.NET anslutningssträng. Du hittar anslutningssträng i Azure-portalen på sidan Anslut ionssträngar för MySQL.
Ange container tabellens namn.
Ange dataChangeDetectionPolicy om data är flyktiga och du vill att indexeraren bara ska hämta de nya och uppdaterade objekten vid efterföljande körningar.
Ange dataDeletionDetectionPolicy om du vill ta bort sökdokument från ett sökindex när källobjektet tas bort.

Skapa ett index

Skapa eller uppdatera index anger indexschemat:

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

Om primärnyckeln i källtabellen matchar dokumentnyckeln (i det här fallet ID) importerar indexeraren primärnyckeln som dokumentnyckel.

Mappa datatyper

I följande tabell mappas MySQL-databasen till Azure AI Search-motsvarigheter. Mer information finns i Datatyper som stöds (Azure AI Search).

Kommentar

Förhandsversionen stöder inte geometrityper och blobar.

MySQL-datatyper	Fälttyper för Azure AI Search
`bool`, `boolean`	Edm.Boolean, Edm.String
`tinyint`, `smallint`, `mediumint`, `int`, , , `integeryear`	Edm.Int32, Edm.Int64, Edm.String
`bigint`	Edm.Int64, Edm.String
`float`, , `doublereal`	Edm.Double, Edm.String
`date`, , `datetimetimestamp`	Edm.DateTimeOffset, Edm.String
`char`, `varchar`, `tinytext`, `mediumtext`, `text`, `longtext`, , `enum`, , `settime`	Edm.String
osignerade numeriska data, seriell, decimal, dec, bit, blob, binär, geometri	Ej tillämpligt

Konfigurera och köra MySQL-indexeraren

När indexet och datakällan har skapats är du redo att skapa indexeraren. Indexerarens konfiguration anger indata, parametrar och egenskaper som styr körningstidsbeteenden.

Skapa eller uppdatera en indexerare genom att ge den ett namn och referera till datakällan och målindexet:

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

Viktiga punkter:

Ange fältmappningar om det finns skillnader i fältnamn eller typ, eller om du behöver flera versioner av ett källfält i sökindexet.
En indexerare körs automatiskt när den skapas. Du kan förhindra att den körs genom att ange disabled till true. Om du vill kontrollera indexerarens körning kör du en indexerare på begäran eller sätter den enligt ett schema.

Kontrollera status för indexerare

Skicka en Get Indexer Status-begäran för att övervaka indexerarens körning:

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

Svaret innehåller status och antalet bearbetade objekt. Det bör se ut ungefär som i följande exempel:

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

Körningshistoriken innehåller upp till 50 av de senast slutförda körningarna, som sorteras i omvänd kronologisk ordning så att den senaste körningen kommer först.

Indexera nya och ändrade rader

När en indexerare har fyllt i ett sökindex fullt ut kanske du vill att efterföljande indexerare körs för att stegvis indexera bara de nya och ändrade raderna i databasen.

Om du vill aktivera inkrementell indexering anger du dataChangeDetectionPolicy egenskapen i datakällans definition. Den här egenskapen talar om för indexeraren vilken mekanism för ändringsspårning som används för dina data.

För Azure Database for MySQL-indexerare är HighWaterMarkChangeDetectionPolicyden enda princip som stöds .

En indexerares princip för ändringsidentifiering förlitar sig på att ha en högvattenmärkeskolumn som fångar upp radversionen eller datum och tid då en rad senast uppdaterades. Det är ofta en DATE, DATETIMEeller TIMESTAMP kolumn med kornighet som räcker för att uppfylla kraven för en högvattenmärkeskolumn.

I MySQL-databasen måste högvattenmärkeskolumnen uppfylla följande krav:

Alla datainfogningar måste ange ett värde för kolumnen.
Alla uppdateringar av ett objekt ändrar också värdet för kolumnen.
Värdet för den här kolumnen ökar med varje infogning eller uppdatering.
Frågor med följande WHERE och ORDER BY -satser kan köras effektivt: WHERE [High Water Mark Column] > [Current High Water Mark Value] ORDER BY [High Water Mark Column]

I följande exempel visas en datakällans definition med en princip för ändringsidentifiering:

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

Viktigt!

Om du använder en vy måste du ange en princip för högvattenmärke i indexerarens datakälla.

Om källtabellen inte har något index för kolumnen högvattenmärke kan frågor som används av MySQL-indexeraren överskrida tidsgränsen. I synnerhet ORDER BY [High Water Mark Column] kräver satsen att ett index körs effektivt när tabellen innehåller många rader.

Indexering av borttagna rader

När rader tas bort från tabellen eller vyn vill du normalt även ta bort dessa rader från sökindexet. Men om raderna tas bort fysiskt från tabellen kan indexeraren inte härleda förekomsten av poster som inte längre finns. Lösningen är att använda en mjuk borttagningsteknik för att logiskt ta bort rader utan att ta bort dem från tabellen. Lägg till en kolumn i tabellen eller vyn och markera rader som borttagna med den kolumnen.

Med en kolumn som ger borttagningstillstånd kan en indexerare konfigureras för att ta bort alla sökdokument för vilka borttagningstillståndet är inställt på true. Konfigurationsegenskapen som stöder det här beteendet är en princip för identifiering av databorttagning som anges i datakällans definition enligt följande:

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

Måste softDeleteMarkerValue vara en sträng. Om du till exempel har en heltalskolumn där borttagna rader har markerats med värdet 1 använder du "1". Om du har en BIT kolumn där borttagna rader har markerats med värdet Boolesk true använder du strängliteralen True eller true (ärendet spelar ingen roll).

Nästa steg

Nu kan du köra indexeraren, övervaka status eller schemalägga indexerarens körning. Följande artiklar gäller för indexerare som hämtar innehåll från Azure MySQL: