Indizieren von Daten von Azure Database for MySQL flexibler Server

Artikel
03/11/2024

Wichtig

Die Unterstützung für MySQL befindet sich derzeit in der öffentlichen Vorschauphase unter Zusätzliche Nutzungsbedingungen. Verwenden Sie eine Vorschau-REST-API (2020-06-30-Preview oder höher), um Ihre Inhalte zu indizieren. Das Portal wird derzeit nicht unterstützt.

In diesem Artikel erfahren Sie, wie Sie einen Indexer konfigurieren, der Inhalte aus Azure Database for MySQL importiert und in Azure KI Search durchsuchbar macht. Die Eingaben für den Indexer sind Ihre Zeilen in einer einzelnen Tabelle oder Ansicht. Die Ausgabe ist ein Suchindex mit durchsuchbaren Inhalten in einzelnen Feldern.

Dieser Artikel ergänzt Erstellen eines Indexers mit Informationen, die spezifisch für die Indizierung von Azure Database for MySQL flexibler Server sind. Er verwendet die REST-APIs, um einen dreiteiligen Workflow zu veranschaulichen, der allen Indexern gemeinsam ist: Erstellen einer Datenquelle, Erstellen eines Indexes und Erstellen eines Indexers. Die Datenextraktion erfolgt, wenn Sie die Anforderung für die Indexererstellung übermitteln.

Wenn der Indexer so konfiguriert ist, dass er einen hohen Grenzwert und vorläufiges Löschen umfasst, übernimmt er alle Änderungen, Uploads und Löschungen für Ihre MySQL-Datenbank. Er spiegelt diese Änderungen in Ihrem Suchindex wider. Die Datenextraktion erfolgt, wenn Sie die Anforderung für die Indexererstellung übermitteln.

Voraussetzungen

Registrieren Sie sich für die Preview, um Feedback zum Szenario zu geben. Sie können das Feature automatisch nach dem Absenden des Formulars aufrufen.
Azure Database for MySQL flexibler Server und Stichprobedaten. Daten müssen sich in einer Tabelle oder Ansicht befinden. Ein Primärschlüssel ist erforderlich. Wenn Sie eine Ansicht verwenden, muss diese eine Spalte mit einem „Hohen Grenzwert“ enthalten.
Leseberechtigungen. Eine Vollzugriff-Verbindungszeichenfolge enthält einen Schlüssel, der Zugriff auf den Inhalt gewährt. Wenn Sie jedoch Azure-Rollen verwenden, stellen Sie sicher, dass die verwaltete Identität des Suchdiensts für MySQL über die Berechtigung Leser verfügt.
Ein REST-Client, um die Datenquelle, den Index und den Indexer zu erstellen.

Sie können auch das Azure SDK für .NET verwenden. Sie können das Portal nicht für die Indexererstellung verwenden, aber Sie können Indexer und Datenquellen verwalten, sobald sie erstellt wurden.

Einschränkungen der Vorschau

Die Änderungsnachverfolgung und die Löscherkennung funktionieren derzeit nicht, wenn Datum oder Zeitstempel für alle Zeilen gleich ist. Diese Einschränkung ist ein bekanntes Problem, das in einem Update für die Vorschauversion behoben wird. Fügen Sie dem MySQL-Indexer kein Skillset hinzu, bis dieses Problem behoben ist.

Die Vorschauversion unterstützt keine Geometrietypen und Blobs.

Wie bereits erwähnt, gibt es keine Portalunterstützung für die Indexererstellung. Ein MySQL-Indexer und eine Datenquelle können jedoch im Portal verwaltet werden, wenn sie vorhanden sind. Beispielsweise können Sie die Definitionen bearbeiten und den Indexer zurücksetzen, ausführen oder planen.

Definieren der Datenquelle

Die Datenquellendefinition gibt die zu indizierenden Daten, die Anmeldeinformationen und die Richtlinien für die Identifizierung von Datenänderungen an. Die Datenquelle wird als unabhängige Ressource definiert, sodass sie von mehreren Indexern verwendet werden kann.

Angaben zur Definition finden Sie unter Erstellen oder Aktualisieren von Datenquellen. Achten Sie darauf, beim Erstellen der Datenquelle eine Vorschau-REST-API (2020-06-30-Preview oder höher) zu verwenden.

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

Die wichtigsten Punkte:

Legen Sie type auf "mysql" fest (erforderlich).
Legen Sie credentials auf eine ADO.NET-Verbindungszeichenfolge fest. Verbindungszeichenfolgen finden Sie in Azure-Portal auf der Seite Verbindungszeichenfolgen für MySQL.
Legen Sie container auf den Namen der Tabelle fest.
Legen Sie dataChangeDetectionPolicy fest, wenn Daten flüchtig sind und der Indexer bei nachfolgenden Ausführungen nur die neuen und aktualisierten Elemente erfassen soll.
Legen Sie dataDeletionDetectionPolicy fest, wenn Sie Suchdokumente aus einem Suchindex entfernen möchten, wenn das Quellelement gelöscht wird.

Erstellen eines Index

Erstellen" oder Aktualisieren des Indexes gibt das Indexschema an:

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

Wenn der Primärschlüssel in der Quelltabelle mit dem Dokumentschlüssel übereinstimmt (in diesem Fall „ID“), importiert der Indexer den Primärschlüssel als Dokumentschlüssel.

Zuordnen von Datentypen

In der folgenden Tabelle wird die MySQL-Datenbank den Entsprechungen in Azure KI Search zugeordnet. Weitere Informationen finden Sie unter Unterstützte Datentypen (Azure KI Search).

Hinweis

Die Preview-Version unterstützt keine Geometrietypen und Blobs.

MySQL-Datentypen	Azure KI Search-Feldtypen
`bool`, `boolean`	Edm.Boolean, Edm.String
`tinyint`, `smallint`, `mediumint`, `int`, `integer`, `year`	Edm.Int32, Edm.Int64, Edm.String
`bigint`	Edm.Int64, Edm.String
`float`, `double`, `real`	Edm.Double, Edm.String
`date`, `datetime`, `timestamp`	Edm.DateTimeOffset, Edm.String
`char`, `varchar`, `tinytext`, `mediumtext`, `text`, `longtext`, `enum`, `set`, `time`	Edm.String
Numerische Daten ohne Vorzeichen, serial, decimal, dec, bit, blob, binary, geometry	Nicht zutreffend

Konfigurieren und Ausführen des MySQL-Indexers

Nach der Erstellung von Index und Datenquelle können Sie den Indexer erstellen. Die Indexerkonfiguration gibt die Eingaben, Parameter und Eigenschaften an, die das Laufzeitverhalten steuern.

Erstellen oder aktualisieren Sie den Indexer, indem Sie ihm einen Namen geben und einen Verweis auf die Datenquelle und den Zielindex hinzufügen:

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

Die wichtigsten Punkte:

Geben Sie Feldzuordnungen an, wenn es Unterschiede beim Feldnamen oder -typ gibt, oder wenn Sie mehrere Versionen eines Quellfelds im Suchindex benötigen.
Ein Indexer wird automatisch ausgeführt, wenn er erstellt wird. Sie können die Ausführung verhindern, indem Sie disabled auf true festlegen. Um die Ausführung des Indexers zu steuern, führen Sie einen Indexer nach Bedarf aus, oder legen Sie für ihn einen Zeitplan fest.

Überprüfen des Indexerstatus

Senden Sie eine Anforderung zum Abrufen des Indexer-Status, um die Indexerausführung zu überwachen:

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

Die Antwort enthält den Status und die Anzahl der verarbeiteten Elemente. Sie sollte in etwa wie das folgende Beispiel aussehen:

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

Der Ausführungsverlauf enthält bis zu 50 der zuletzt abgeschlossenen Ausführungen. Diese sind in umgekehrter chronologischer Reihenfolge sortiert, sodass die neueste Ausführung als Erstes aufgelistet wird.

Indizieren neuer und geänderter Zeilen

Sobald ein Indexer einen Suchindex vollständig aufgefüllt hat, sollen nachfolgende Indexerläufe möglicherweise nur die neuen und geänderten Zeilen in Ihrer Datenbank inkrementell indizieren.

Wenn Sie die inkrementelle Indizierung aktivieren möchten, legen Sie die Eigenschaft dataChangeDetectionPolicy in Ihrer Datenquellendefinition fest. Diese Eigenschaft teilt dem Indexer mit, welcher Mechanismus für die Änderungsnachverfolgung für Ihre Daten verwendet wird.

Für Azure Database for MySQL-Indexer ist die einzige unterstützte Richtlinie HighWaterMarkChangeDetectionPolicy.

Die Änderungserkennungsrichtlinie eines Indexers basiert auf dem Vorhandensein einer Spalte mit hohem Grenzwert, in der die Zeilenversion oder Datum und Uhrzeit der letzten Aktualisierung einer Zeile erfasst werden. Es handelt sich häufig um eine DATE-, DATETIME- oder TIMESTAMP-Spalte mit einer Granularität, die ausreicht, um die Anforderungen einer Spalte mit hohem Grenzwert zu erfüllen.

In Ihrer MySQL-Datenbank muss die „Hoher Grenzwert“-Spalte die folgenden Anforderungen erfüllen:

Alle Dateneinfügungen müssen einen Wert für die Spalte angeben.
Alle Updates für ein Element ändern auch den Wert der Spalte.
Der Wert dieser Spalte wird bei jeder Einfügung oder Aktualisierung erhöht.
Abfragen mit den folgenden WHERE- und ORDER BY-Klauseln können effizient ausgeführt werden: WHERE [High Water Mark Column] > [Current High Water Mark Value] ORDER BY [High Water Mark Column]

Das folgende Beispiel zeigt eine Datenquellendefinition mit einer Änderungserkennungsrichtlinie:

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

Wichtig

Wenn Sie eine Sicht verwenden, müssen Sie eine „Hoher Grenzwert“-Richtlinie in Ihrer Indexerdatenquelle festlegen.

Wenn die Quelltabelle keinen Index für die Spalte mit hohem Grenzwert enthält, kann das Zeitlimit für die vom MySQL-Indexer verwendeten Abfragen überschritten werden. Insbesondere die Klausel ORDER BY [High Water Mark Column] erfordert für die effiziente Ausführung einen Index, wenn die Tabelle viele Zeilen enthält.

Indizieren gelöschter Zeilen

Wenn Zeilen aus der Tabelle oder Sicht gelöscht werden, möchten Sie diese Zeilen in der Regel auch aus dem Suchindex löschen. Wenn Zeilen jedoch physisch aus der Tabelle entfernt werden, hat ein Indexer keine Möglichkeit, das Vorhandensein von Datensätzen, die nicht mehr vorhanden sind, abzuleiten. Die Lösung hierfür besteht darin, eine Methode für vorläufiges Löschen zu verwenden, um Zeilen logisch zu löschen, ohne sie aus der Tabelle zu entfernen. Fügen Sie dazu der Tabelle eine Spalte hinzu, um Zeilen unter Verwendung dieser Spalte anzuzeigen und als gelöscht zu markieren.

Bei einer Spalte, die den Löschzustand angibt, kann ein Indexer so konfiguriert werden, dass alle Suchdokumente entfernt werden, für die der Löschzustand auf true festgelegt ist. Die Konfigurationseigenschaft, die dieses Verhalten unterstützt, ist eine Richtlinie zur Erkennung von Datenlöschungen, die in der Datenquellendefinition wie folgt angegeben wird:

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

Der softDeleteMarkerValue muss eine Zeichenfolge sein. Wenn Sie z.B. über eine „integer“-Spalte verfügen, in der gelöschte Zeilen durch den Wert 1 gekennzeichnet sind, verwenden Sie "1". Wenn Sie über eine BIT-Spalte verfügen, in der gelöschte Zeilen durch den booleschen Wert „True“ gekennzeichnet sind, verwenden Sie das Zeichenfolgenliteral True oder true (die Groß- und Kleinschreibung spielt keine Rolle).

Nächste Schritte

Sie können nun den Indexer ausführen, den Status überwachen oder die Ausführung des Indexers planen. Die folgenden Artikel gelten für Indexer, die Inhalte mithilfe von Pull Requests aus Azure MySQL übertragen: