Indexovat data z Azure SQL

v tomto článku se dozvíte, jak nakonfigurovat indexer služby Azure SQL pro extrakci obsahu a zpřístupnění jeho prohledávání v Azure Kognitivní hledání. tento pracovní postup vytvoří index vyhledávání v Azure Kognitivní hledání a načte ho pomocí existujícího obsahu extrahovaného z Azure SQL Database a spravovaných instancí Azure SQL.

tento článek se věnuje mechanismu použití indexerů, ale také popisuje funkce, které jsou k dispozici pouze pro Azure SQL Database nebo SQL spravované Instance (například integrované sledování změn).

službu Azure SQL indexer můžete nastavit pomocí kteréhokoli z těchto klientů:

• Azure Portal
• REST API kognitivní hledání Azure
• Sada Azure Kognitivní hledání .NET SDK

Tento článek používá rozhraní REST API.

Požadavky

• Data pocházejí z jedné tabulky nebo zobrazení. Pokud jsou data rozptýlená napříč více tabulkami, můžete vytvořit jedno zobrazení dat. nevýhodou použití zobrazení je, že nebudete moci použít SQL Server integrované zjišťování změn k aktualizaci indexu pomocí přírůstkových změn. Další informace najdete v tématu zachytávání změněných a odstraněných řádků níže.

• Datové typy musí být kompatibilní. ve vyhledávacím indexu není podporována většina typů SQL. Seznam najdete v tématu mapování datových typů.

• připojení ke spravované instanci SQL musí být prostřednictvím veřejného koncového bodu. Další informace najdete v tématu připojení indexeru prostřednictvím veřejného koncového bodu.

• připojení k SQL Server na virtuálním počítači Azure vyžaduje ruční nastavení bezpečnostního certifikátu. další informace najdete v tématu připojení indexeru k SQL Server na virtuálním počítači Azure.

Synchronizace dat v reálném čase nesmí být požadavkem na aplikaci. Indexer může tabulku znovu indexovat každých pět minut. Pokud se data často mění a tyto změny se musí projevit v indexu během několika sekund nebo v jednom minutách, doporučujeme použít sadu REST API nebo .NET SDK k přímému nabízení aktualizovaných řádků.

Je možné přírůstkové indexování. Pokud máte rozsáhlou sadu dat a plánujete spustit indexer podle plánu, Azure Kognitivní hledání musí být schopný efektivně identifikovat nové, změněné nebo odstraněné řádky. Nepřírůstkové indexování je povolené jenom v případě, že indexování provádíte na vyžádání (ne podle plánu) nebo je vyplněné méně než 100 000 řádků. Další informace najdete v tématu zachytávání změněných a odstraněných řádků níže.

Azure Kognitivní hledání podporuje ověřování SQL Server, kde je zadané uživatelské jméno a heslo v připojovacím řetězci. Případně můžete nastavit spravovanou identitu a použít role Azure k vynechání přihlašovacích údajů k připojení. Další informace najdete v tématu nastavení připojení indexeru pomocí spravované identity.

vytvoření indexeru služby Azure SQL

1. Vytvoření zdroje dat:

    POST https://myservice.search.windows.net/datasources?api-version=2020-06-30
    Content-Type: application/json
    api-key: admin-key
   
    {
        "name" : "myazuresqldatasource",
        "type" : "azuresql",
        "credentials" : { "connectionString" : "Server=tcp:<your server>.database.windows.net,1433;Database=<your database>;User ID=<your user name>;Password=<your password>;Trusted_Connection=False;Encrypt=True;Connection Timeout=30;" },
        "container" : { "name" : "name of the table or view that you want to index" }
    }
   

   Připojovací řetězec může následovat po jednom z následujících formátů:

   1. Připojovací řetězec můžete získat z Azure Portal; použijte ADO.NET connection string možnost.
   2. Spravovaný připojovací řetězec identity, který neobsahuje klíč účtu v následujícím formátu: Initial Catalog|Database=<your database name>;ResourceId=/subscriptions/<your subscription ID>/resourceGroups/<your resource group name>/providers/Microsoft.Sql/servers/<your SQL Server name>/;Connection Timeout=connection timeout length; . pokud chcete použít tento připojovací řetězec, postupujte podle pokynů pro nastavení připojení indexeru k Azure SQL Database pomocí spravované identity.

2. Pokud ho ještě nemáte, vytvořte cílový index Azure Kognitivní hledání. Index můžete vytvořit pomocí portálu nebo rozhraní API pro vytvoření indexu. ujistěte se, že schéma cílového indexu je kompatibilní se schématem zdrojové tabulky – viz mapování mezi SQL a typy dat vyhledávání v Azure.

3. Vytvořte indexer tak, že mu udělíte název a odkazujete na zdroj dat a cílový index:

    POST https://myservice.search.windows.net/indexers?api-version=2020-06-30
    Content-Type: application/json
    api-key: admin-key
   
    {
        "name" : "myindexer",
        "dataSourceName" : "myazuresqldatasource",
        "targetIndexName" : "target index name"
    }
   

Indexer vytvořený tímto způsobem nemá plán. Automaticky se spustí při vytvoření. Můžete ji kdykoli znovu spustit pomocí žádosti indexeru Run :

    POST https://myservice.search.windows.net/indexers/myindexer/run?api-version=2020-06-30
    api-key: admin-key

Můžete přizpůsobit několik aspektů chování indexeru, jako je velikost dávky, a počet dokumentů, které je možné přeskočit předtím, než se spuštění indexeru nezdařilo. Další informace najdete v tématu Vytvoření rozhraní API pro indexer.

Možná budete muset službě Azure dovolit připojení k vaší databázi. Pokyny k tomu, jak to udělat, najdete v tématu připojení z Azure .

Pokud chcete monitorovat stav indexeru a historii spouštění (počet položek indexovaných, selhání atd.), použijte požadavek na stav indexeru :

    GET https://myservice.search.windows.net/indexers/myindexer/status?api-version=2020-06-30
    api-key: admin-key

Odpověď by měla vypadat nějak takto:

    {
        "@odata.context":"https://myservice.search.windows.net/$metadata#Microsoft.Azure.Search.V2015_02_28.IndexerExecutionInfo",
        "status":"running",
        "lastResult": {
            "status":"success",
            "errorMessage":null,
            "startTime":"2015-02-21T00:23:24.957Z",
            "endTime":"2015-02-21T00:36:47.752Z",
            "errors":[],
            "itemsProcessed":1599501,
            "itemsFailed":0,
            "initialTrackingState":null,
            "finalTrackingState":null
        },
        "executionHistory":
        [
            {
                "status":"success",
                "errorMessage":null,
                "startTime":"2015-02-21T00:23:24.957Z",
                "endTime":"2015-02-21T00:36:47.752Z",
                "errors":[],
                "itemsProcessed":1599501,
                "itemsFailed":0,
                "initialTrackingState":null,
                "finalTrackingState":null
            },
            ... earlier history items
        ]
    }

Historie spouštění obsahuje až 50 posledních dokončených provedení, která jsou seřazena v obráceném chronologickém pořadí (takže se poslední spuštění v odpovědi zařadí jako první). Další informace o odpovědi najdete v části získání stavu indexeru .

Spustit indexery podle plánu

Indexer je také možné uspořádat tak, aby běžel pravidelně podle plánu. Chcete-li to provést, přidejte při vytváření nebo aktualizaci indexeru vlastnost Schedule . Následující příklad ukazuje požadavek PUT na aktualizaci indexeru:

    PUT https://myservice.search.windows.net/indexers/myindexer?api-version=2020-06-30
    Content-Type: application/json
    api-key: admin-key

    {
        "dataSourceName" : "myazuresqldatasource",
        "targetIndexName" : "target index name",
        "schedule" : { "interval" : "PT10M", "startTime" : "2015-01-01T00:00:00Z" }
    }

Parametr interval je povinný. Tento interval odkazuje na čas mezi začátkem dvou po sobě jdoucích spuštění indexeru. Nejmenší povolený interval je 5 minut. nejdelší je jeden den. Musí být formátován jako hodnota XSD "dayTimeDuration" (omezená podmnožina hodnoty Duration ISO 8601 ). Vzor pro tuto hodnotu je: P(nD)(T(nH)(nM)) . Příklady: PT15M každých 15 minut každé PT2H 2 hodiny.

Další informace o definování plánů indexerů najdete v tématu postup plánování indexerů pro Azure kognitivní hledání.

Zaznamenání nových, změněných a odstraněných řádků

Azure Kognitivní hledání používá přírůstkové indexování k tomu, aby nemusela znovu indexovat celou tabulku nebo zobrazit při každém spuštění indexeru. Azure Kognitivní hledání poskytuje dvě zásady zjišťování změn pro podporu přírůstkového indexování.

SQL Zásady integrovaného Change Tracking

pokud vaše databáze SQL podporuje sledování změn, doporučujeme použít zásady SQL integrované Change Tracking. Toto je nejúčinnější zásada. Kromě toho umožňuje službě Azure Kognitivní hledání identifikovat odstraněné řádky, aniž byste museli do tabulky přidat explicitní sloupec "obnovitelné odstranění".

Požadavky

• Požadavky na verzi databáze:
  • pokud používáte SQL Server na virtuálních počítačích Azure, SQL Server 2012 SP3 a novější.
  • Azure SQL Database nebo SQL spravované Instance.
• Pouze tabulky (žádná zobrazení).
• V databázi Povolte sledování změn pro tabulku.
• V tabulce není žádný složený primární klíč (primární klíč, který obsahuje více než jeden sloupec).

Využití

Chcete-li použít tuto zásadu, vytvořte nebo aktualizujte zdroj dat takto:

    {
        "name" : "myazuresqldatasource",
        "type" : "azuresql",
        "credentials" : { "connectionString" : "connection string" },
        "container" : { "name" : "table or view name" },
        "dataChangeDetectionPolicy" : {
           "@odata.type" : "#Microsoft.Azure.Search.SqlIntegratedChangeTrackingPolicy"
      }
    }

při použití SQL integrovaných zásad sledování změn nezadávejte samostatné zásady zjišťování odstranění dat – tato zásada má integrovanou podporu pro identifikaci odstraněných řádků. aby se ale u odstranění zjistila hodnota "automagic", klíč dokumentu v indexu hledání musí být stejný jako primární klíč v tabulce SQL.

Zásada pro detekci změny vysokého měřítka

Tato zásada detekce změn spoléhá na sloupec horní meze, ve kterém se zachytí verze nebo čas poslední aktualizace řádku. Pokud používáte zobrazení, je nutné použít zásady vysoké značky. Sloupec horních značek musí splňovat následující požadavky.

Požadavky

• Všechna vložení určují hodnotu sloupce.
• Všechny aktualizace položky také změní hodnotu sloupce.
• Hodnota tohoto sloupce se zvětšuje s každým vložením nebo aktualizací.
• Dotazy s následujícími klauzulemi WHERE a ORDER BY mohou být provedeny efektivně: WHERE [High Water Mark Column] > [Current High Water Mark Value] ORDER BY [High Water Mark Column]

Využití

Chcete-li použít zásady vysoké značky, vytvořte nebo aktualizujte zdroj dat takto:

    {
        "name" : "myazuresqldatasource",
        "type" : "azuresql",
        "credentials" : { "connectionString" : "connection string" },
        "container" : { "name" : "table or view name" },
        "dataChangeDetectionPolicy" : {
           "@odata.type" : "#Microsoft.Azure.Search.HighWaterMarkChangeDetectionPolicy",
           "highWaterMarkColumnName" : "[a rowversion or last_updated column name]"
      }
    }

convertHighWaterMarkToRowVersion

Pokud pro sloupec s vysokou hodnotou vody používáte datový typ rowversion, zvažte použití nastavení convertHighWaterMarkToRowVersion konfigurace indexeru. convertHighWaterMarkToRowVersion má dvě věci:

• Použijte datový typ rowversion pro sloupec vysoké hodnoty vody v dotazu SQL indexeru. Použití správného datového typu zlepšuje výkon dotazů indexeru.
• Před spuštěním dotazu indexeru odečtěte od hodnoty rowversion hodnotu 1. Zobrazení s 1 až mnoha spojeními mohou mít řádky s duplicitními hodnotami rowversion. Odečtením hodnoty 1 zajistíte, že dotaz indexeru tyto řádky nezmešká.

Pokud chcete tuto funkci povolit, vytvořte nebo aktualizujte indexer s následující konfigurací:

    {
      ... other indexer definition properties
     "parameters" : {
            "configuration" : { "convertHighWaterMarkToRowVersion" : true } }
    }

queryTimeout (časový limit dotazu)

Pokud dojde k chybám časového limitu, můžete pomocí nastavení konfigurace indexeru nastavit časový limit dotazu na vyšší hodnotu, než je výchozí časový limit queryTimeout 5 minut. Pokud například chcete nastavit časový limit na 10 minut, vytvořte nebo aktualizujte indexer s následující konfigurací:

    {
      ... other indexer definition properties
     "parameters" : {
            "configuration" : { "queryTimeout" : "00:10:00" } }
    }

disableOrderByHighWaterMarkColumn

Můžete také zakázat ORDER BY [High Water Mark Column] klauzuli . To se ale nedoporučuje, protože pokud je provádění indexeru přerušeno chybou, musí indexer znovu zpracovat všechny řádky, pokud se spustí později – i když indexer již zpracuje téměř všechny řádky v době, kdy byl přerušen. Pokud chcete ORDER BY klauzuli zakázat, použijte disableOrderByHighWaterMarkColumn nastavení v definici indexeru:

    {
     ... other indexer definition properties
     "parameters" : {
            "configuration" : { "disableOrderByHighWaterMarkColumn" : true } }
    }

Zásady detekce odstranění sloupců směšování odstranění

Při odstranění řádků ze zdrojové tabulky budete pravděpodobně chtít odstranit i tyto řádky z indexu vyhledávání. Pokud použijete SQL integrovaných zásad sledování změn, postará se o to za vás. Zásady sledování změn ve vysokých náodocích vám ale s odstraněné řádky nepomáhou. Co dělat?

Pokud jsou řádky fyzicky odebrány z tabulky, Azure Cognitive Search způsob, jak odvodit přítomnost záznamů, které už neexistují. Techniku "soft-delete" ale můžete použít 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.

Při použití techniky softwarového odstranění můžete při vytváření nebo aktualizaci zdroje dat zadat zásady softwarového odstranění 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]"
        }
    }

SoftDeleteMarkerValue musí být řetězec – použijte řetězcové vyjádření skutečné hodnoty. Pokud máte například sloupec s celým číslem, kde jsou odstraněné řádky označené hodnotou 1, použijte "1" . Pokud máte sloupec BIT, kde jsou odstraněné řádky označené logickou hodnotou true, použijte řetězcový literál nebo , na případu True true nezáleží.

Mapování mezi SQL a Azure Cognitive Search datovými typy

Konfigurace Nastavení

SQL indexer zveřejňuje několik nastavení konfigurace:

Tato nastavení se používají v parameters.configuration objektu v definici indexeru. Pokud například chcete nastavit časový limit dotazu na 10 minut, vytvořte nebo aktualizujte indexer s následující konfigurací:

    {
      ... other indexer definition properties
     "parameters" : {
            "configuration" : { "queryTimeout" : "00:10:00" } }
    }

Časté otázky

Otázka: Můžu azure SQL indexer s SQL databázemi běžící na virtuálních počítači IaaS v Azure?

Ano. Musíte ale povolit, aby se vaše vyhledávací služba mohla připojit k vaší databázi. Další informace najdete v tématu Konfigurace připojení z Azure Cognitive Search indexeru pro SQL Server na virtuálním počítači Azure.

Otázka: Můžu azure SQL indexer používat s SQL databázemi spuštěných místně?

Ne přímo. Přímé připojení nedoporučujeme ani nepodporujeme, protože by to vyžadovalo, abyste své databáze otevřeli pro internetový provoz. Zákazníci v tomto scénáři uspěli s využitím technologií přemostění, jako je Azure Data Factory. Další informace najdete v tématu Nabízení dat do indexu Azure Cognitive Search pomocí Azure Data Factory.

Otázka: Můžu azure SQL indexer používat s jinými databázemi než SQL Server běžící v IaaS v Azure?

No. Tento scénář nepodporujeme, protože jsme indexer neotestovali s žádnou jinou databází než SQL Server.

Otázka: Můžu vytvořit několik indexerů spuštěných podle plánu?

Ano. Na jednom uzlu ale může být současně spuštěný pouze jeden indexer. Pokud potřebujete, aby souběžně běželo více indexerů, zvažte škálování vyhledávací služby na více než jednu jednotku vyhledávání.

Otázka: Má spuštění indexeru vliv na úlohy dotazů?

Ano. Indexer běží na jednom z uzlů ve vyhledávací službě a prostředky tohoto uzlu se sdílí mezi indexováním a obsluhujícím provozem dotazů a dalšími požadavky rozhraní API. Pokud spustíte náročné indexování a úlohy dotazů a dojde k vysoké frekvenci 503 chyb nebo prodloužení doby odezvy, zvažte navýšení kapacity vyhledávací služby.

Otázka: Můžu jako zdroj dat použít sekundární repliku v clusteru s podporou převzetí služeb při selhání?

To závisí na okolnostech. K úplnému indexování tabulky nebo zobrazení můžete použít sekundární repliku.

V případě přírůstkového indexování Azure Cognitive Search dvě zásady detekce změn: SQL integrované sledování změn a vysoko water mark.

U replik jen pro čtení SQL Database integrované sledování změn. Proto musíte použít zásady pro vysokou úroveň vodoznářů.

Naším standardním doporučením je použít datový typ rowversion pro sloupec s vysokou hodnotou vody. Použití rowversion ale spoléhá na funkci , která není u replik jen pro MIN_ACTIVE_ROWVERSION čtení podporována. Proto pokud používáte verzi řádku, musíte indexer namílit na primární repliku.

Pokud se pokusíte použít rowversion na replice jen pro čtení, zobrazí se následující chyba:

"Použití sloupce rowversion pro sledování změn není podporováno v sekundárních replikách dostupnosti (jen pro čtení). Aktualizujte zdroj dat a zadejte připojení k primární replice dostupnosti. Aktuální vlastnost aktualizovatelnosti databáze je READ_ONLY.

Otázka: Můžu pro sledování změn ve vysokých ná water markech použít alternativní sloupec bez rowversion?

Nedoporučuje se to. Spolehlivá synchronizace dat umožňuje pouze rowversion. V závislosti na logice aplikace ale může být bezpečné v případě, že:

• Můžete zajistit, aby při spuštění indexeru nebyly v indexované tabulce žádné nevyřízené transakce (například všechny aktualizace tabulek proběhnou podle plánu jako dávka a plán indexeru Azure Cognitive Search je nastavený tak, aby se zabránilo překrývání s plánem aktualizace tabulky).

• Pravidelně provádíte úplnou reindexaci, aby se přebraly všechny zmeškané řádky.