Indexdata från Azure Database for MySQL Flexible Server (förhandsversion)

Azure Database for MySQL-indexeraren (förhandsversion) importerar innehåll från Azure Database for MySQL Flexible Server till ett index i Azure AI-sökning. Indata till indexeraren är rader från en enda tabell eller vy. Resultatet är ett sökindex med sökbart innehåll inom enskilda fält.

Den här artikeln kompletterar Skapa en indexerare med information som är specifik för indexering från Azure Database for MySQL flexibel 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

• Fyll i registreringsformuläret för indexerarens förhandsversion. Registreringen godkänns automatiskt.

• Azure Database for MySQL Flexibel Server och provdata. 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 full åtkomst reťazec pripojenia innehåller en nyckel som ger åtkomst till innehållet, men om du använder Azure-roller kontrollerar du att search service managed identity har Reader behörighet på MySQL.

• En REST-klient för att skapa datakällan, indexet och indexeraren.

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

Förhandsversionsbegränsningar

För närvarande fungerar inte ändringsspårning och radering detektering 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 Azure 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 ett REST API för förhandsversion 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ängar i Azure portalen på sidan Anslutningssträ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.

Kartlägga datatyper

I följande tabell mappas MySQL-databasen till Azure AI-sökning motsvarigheter. Mer information finns i Supported datatyper (Azure AI-sökning).

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 indexerarens status

Skicka en begäran om hämta indexerstatus för att övervaka indexerarens exekvering.

GET https://myservice.search.windows.net/indexers/myindexer/status?api-version=2026-08-01-preview
  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, och de sorteras i omvänd kronologisk ordning så att den senaste körningen visas 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 den enda princip som stöds HighWaterMarkChangeDetectionPolicy.

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

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:

• Indexering av stora datamängder
• Indexer åtkomst till innehåll som skyddas av Azure nätverkssäkerhetsfunktioner