Indexování dat z flexibilního serveru Azure Database for MySQL

Článek
12/10/2024

Důležité

Podpora MySQL je aktuálně ve verzi Public Preview v rámci dodatečných podmínek použití. K indexování obsahu můžete použít verzi 2020-06-30-preview nebo novější. Doporučujeme nejnovější rozhraní API ve verzi Preview. V současné době není k dispozici žádná podpora portálu.

V tomto článku se dozvíte, jak nakonfigurovat indexer , který importuje obsah ze služby Azure Database for MySQL a umožňuje vyhledávání ve službě Azure AI Search. Vstupy do indexeru jsou váš řádek v jedné tabulce nebo zobrazení. Výstup je index vyhledávání s prohledávatelným obsahem v jednotlivých polích.

Tento článek doplňuje vytvoření indexeru s informacemi specifickými pro indexování z flexibilního serveru Azure Database for MySQL. Pomocí rozhraní REST API demonstruje třídílný pracovní postup společný pro všechny indexery: vytvoření zdroje dat, vytvoření indexeru a vytvoření indexeru. Extrakce dat nastane, když odešlete požadavek Create Indexer.

Když je nakonfigurované tak, aby zahrnovaly vysokou mez a obnovitelné odstranění, indexer provede všechny změny, nahraje a odstraní vaši databázi MySQL. Tyto změny se projeví v indexu vyhledávání. Extrakce dat nastane, když odešlete požadavek Create Indexer.

Požadavky

Zaregistrujte si verzi Preview a poskytněte nám zpětnou vazbu ke scénáři. K funkci se dostanete automaticky po odeslání formuláře.
Flexibilní server Azure Database for MySQL a ukázková data Data se musí nacházet v tabulce nebo zobrazení. Je vyžadován primární klíč. Pokud používáte zobrazení, musí mít sloupec horní meze.
Oprávnění ke čtení Úplný přístup připojovací řetězec zahrnuje klíč, který uděluje přístup k obsahu, ale pokud používáte role Azure, ujistěte se, že spravovaná identita vyhledávací služby má v MySQL oprávnění čtenáře.
Klient REST pro vytvoření zdroje dat, indexu a indexeru.

Můžete také použít sadu Azure SDK pro .NET. K vytvoření indexeru nemůžete použít Azure Portal, ale po vytvoření můžete spravovat indexery a zdroje dat.

Omezení verze Preview

Detekce sledování změn a odstranění v současné době nefunguje, pokud je datum nebo časové razítko jednotné pro všechny řádky. Toto omezení je známý problém, který je potřeba vyřešit v aktualizaci verze Preview. Dokud se tento problém nevyřeší, nepřidávejte do indexeru MySQL sadu dovedností.

Náhled nepodporuje typy geometrie a objekty blob.

Jak jsme uvedli, neexistuje žádná podpora vytváření indexeru na portálu, ale indexer MySQL a zdroj dat je možné spravovat na webu Azure Portal, jakmile existují. Můžete například upravit definice a resetovat, spustit nebo naplánovat indexer.

Definování zdroje dat

Definice zdroje dat určuje data, která se mají indexovat, přihlašovací údaje a zásady pro identifikaci změn v datech. Zdroj dat je definován jako nezávislý prostředek, aby ho mohl používat více indexerů.

Vytvoření nebo aktualizace zdroje dat určuje definici. Při vytváření zdroje dat nezapomeňte použít rozhraní REST API ve verzi Preview.

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

Klíčové body:

Nastaveno type na "mysql" (povinné).
Nastavte credentials na ADO.NET připojovací řetězec. Připojovací řetězec najdete na webu Azure Portal na stránce Připojovací řetězce pro MySQL.
Nastavte container na název tabulky.
Nastavte dataChangeDetectionPolicy , jestli jsou data nestálá a chcete, aby indexer zvedá pouze nové a aktualizované položky v následných spuštěních.
Nastavte dataDeletionDetectionPolicy , pokud chcete odebrat vyhledávací dokumenty z indexu vyhledávání při odstranění zdrojové položky.

Vytvoření indexu

Vytvoření nebo aktualizace indexu určuje schéma indexu:

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

Pokud primární klíč ve zdrojové tabulce odpovídá klíči dokumentu (v tomto případě "ID"), indexer naimportuje primární klíč jako klíč dokumentu.

Mapování datových typů

Následující tabulka mapuje databázi MySQL na ekvivalenty služby Azure AI Search. Další informace najdete v tématu Podporované datové typy (Azure AI Search).

Poznámka:

Verze Preview nepodporuje typy geometrie a objekty blob.

Datové typy MySQL	Typy polí 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`, , `mediumtextlongtextenumtinytexttext`, , `settime`	Edm.String
unsigned numeric data, serial, decimal, dec, bit, blob, binary, geometry	–

Konfigurace a spuštění indexeru MySQL

Po vytvoření indexu a zdroje dat můžete indexer vytvořit. Konfigurace indexeru určuje vstupy, parametry a vlastnosti, které řídí chování doby běhu.

Vytvořte nebo aktualizujte indexer tak, že ho pojmenujte a odkazujete na zdroj dat a cílový index:

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

Klíčové body:

Určete mapování polí, pokud existují rozdíly v názvu nebo typu pole nebo pokud potřebujete v indexu vyhledávání více verzí zdrojového pole.
Indexer se spustí automaticky při jeho vytvoření. Spuštění můžete zabránit nastavením disabled na true. Pokud chcete řídit provádění indexeru, spusťte indexer na vyžádání nebo ho umístěte do plánu.

Kontrola stavu indexeru

Odeslání žádosti o získání stavu indexeru pro monitorování provádění indexeru:

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

Odpověď zahrnuje stav a počet zpracovaných položek. Měl by vypadat podobně jako v následujícím příkladu:

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

Historie provádění obsahuje až 50 naposledy dokončených spuštění, které jsou seřazeny v obráceném chronologickém pořadí tak, aby poslední spuštění bylo první.

Indexování nových a změněné řádky

Jakmile indexer plně naplní vyhledávací index, můžete chtít, aby následující indexer běžel postupně indexovat pouze nové a změněné řádky v databázi.

Pokud chcete povolit přírůstkové indexování, nastavte dataChangeDetectionPolicy vlastnost v definici zdroje dat. Tato vlastnost říká indexeru, který mechanismus sledování změn se používá u vašich dat.

Pro indexery Azure Database for MySQL platí, že jedinou podporovanou zásadou HighWaterMarkChangeDetectionPolicyje .

Zásady detekce změn indexeru spoléhají na to, že má sloupec s vysokou hladinou, který zachycuje verzi řádku nebo datum a čas poslední aktualizace řádku. Často se jedná o DATEsloupec nebo , DATETIMETIMESTAMP který je dostatečně členitý pro splnění požadavků sloupce horní značky.

Ve vaší databázi MySQL musí sloupec horní značky splňovat následující požadavky:

Všechna vložení dat musí určovat hodnotu sloupce.
Všechny aktualizace položky také změní hodnotu sloupce.
Hodnota tohoto sloupce se zvyšuje při každém vložení nebo aktualizaci.
Dotazy s následujícími WHERE klauzulemi a ORDER BY klauzulemi je možné efektivně spouštět: WHERE [High Water Mark Column] > [Current High Water Mark Value] ORDER BY [High Water Mark Column]

Následující příklad ukazuje definici zdroje dat se zásadami detekce změn:

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

Důležité

Pokud používáte zobrazení, musíte ve zdroji dat indexeru nastavit zásadu horní značky.

Pokud zdrojová tabulka nemá index ve sloupci horní značky, může dojít k vypršení časového limitu dotazů používaných indexerem MySQL. Konkrétně klauzule vyžaduje efektivní ORDER BY [High Water Mark Column] spuštění indexu, pokud tabulka obsahuje mnoho řádků.

Indexování odstraněných řádků

Když se řádky odstraní z tabulky nebo zobrazení, obvykle je chcete odstranit také z indexu vyhledávání. Pokud jsou však řádky fyzicky odebrány z tabulky, indexer nemá žádný způsob, jak odvodit přítomnost záznamů, které již neexistují. Řešením je použít metodu obnovitelného odstranění k logickému odstranění řádků bez jejich odebrání z tabulky. Přidejte sloupec do tabulky nebo zobrazení a označte řádky jako odstraněné pomocí tohoto sloupce.

Vzhledem k tomu, že sloupec, který poskytuje stav odstranění, lze indexer nakonfigurovat tak, aby odebral všechny vyhledávací dokumenty, na které je stav odstranění nastavený true. Vlastnost konfigurace, která toto chování podporuje, je zásada detekce odstranění dat, která je zadaná v definici zdroje dat následujícím způsobem:

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

Musí softDeleteMarkerValue to být řetězec. Pokud máte například celočíselnou hodnotu, ve které jsou odstraněné řádky označené hodnotou 1, použijte "1". Pokud máte BIT sloupec, ve kterém jsou odstraněné řádky označené logickou hodnotou true, použijte řetězcový literál True nebo true (případ nezáleží).

Další kroky

Teď můžete spustit indexer, monitorovat stav nebo naplánovat spuštění indexeru. Následující články platí pro indexery, které načítá obsah z Azure MySQL:

Sdílet prostřednictvím