Indexera data från Azure SQL

Den här artikeln visar hur du konfigurerar en Azure SQL-indexerare för att extrahera innehåll och göra det sökbart i Azure Cognitive Search. Det här arbetsflödet skapar ett sökindex på Azure Cognitive Search och läser in det med befintligt innehåll som extraherats från Azure SQL Database och Azure SQL hanterade instanser.

Den här artikeln beskriver hur du använder indexerare,men beskriver även funktioner som endast är tillgängliga med Azure SQL Database eller SQL Managed Instance (till exempel integrerad ändringsspårning).

Du kan konfigurera en Azure SQL-indexerare med någon av följande klienter:

• Azure-portalen
• Azure Cognitive Search REST API
• Azure Cognitive Search .NET SDK

I den här artikeln används REST-API:er.

Förutsättningar

• Data kommer från en enskild tabell eller vy. Om data är spridda över flera tabeller kan du skapa en enda vy av data. En nackdel med att använda vyn är att du inte kan använda SQL Server integrerad ändringsidentifiering för att uppdatera ett index med inkrementella ändringar. Mer information finns i Samla in ändrade och borttagna rader nedan.

• Datatyper måste vara kompatibla. De flesta men inte alla SQL-typer stöds i ett sökindex. En lista finns i Mappa datatyper.

• Anslutningar till en SQL-hanterad instans måste ske via en offentlig slutpunkt. Mer information finns i Indexeraranslutningar via en offentlig slutpunkt.

• Anslutningar till SQL Server på en virtuell Azure-dator kräver manuell konfigurera ett säkerhetscertifikat. Mer information finns i Indexeraranslutningar till en SQL Server på en virtuell Azure-dator.

Datasynkronisering i realtid får inte vara ett programkrav. En indexerare kan indexera om tabellen som mest var femte minut. Om dina data ändras ofta och dessa ändringar måste återspeglas i indexet inom några sekunder eller bara några minuter rekommenderar vi att du använder REST API eller .NET SDK för att skicka uppdaterade rader direkt.

Inkrementell indexering är möjlig. Om du har en stor datauppsättning och planerar att köra indexeraren enligt ett schema Azure Cognitive Search du effektivt kunna identifiera nya, ändrade eller borttagna rader. Icke-inkrementell indexering tillåts endast om du indexerar på begäran (inte enligt schemat) eller om du indexerar färre än 100 000 rader. Mer information finns i Samla in ändrade och borttagna rader nedan.

Azure Cognitive Search stöder SQL Server autentisering, där användarnamn och lösenord anges i anslutningssträngen. Du kan också konfigurera en hanterad identitet och använda Azure-roller för att utelämna autentiseringsuppgifter för anslutningen. Mer information finns i Konfigurera en indexeraranslutning med en hanterad identitet.

Skapa en Azure SQL Indexer

1. Skapa datakällan:

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

   Anslutningssträngen kan följa något av formaten nedan:

   1. Du kan hämta anslutningssträngen från Azure Portal; använd ADO.NET connection string alternativet .
   2. En anslutningssträng för hanterad identitet som inte innehåller en kontonyckel i följande format: 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; . Om du vill använda den här anslutningssträngen följer du anvisningarna för Att konfigurera en indexeraranslutning till en Azure SQL Database med en hanterad identitet.

2. Skapa målindexet Azure Cognitive Search om du inte redan har ett. Du kan skapa ett index med hjälp av portalen eller skapa index-API:et. Se till att schemat för målindexet är kompatibelt med schemat för källtabellen – se mappning mellan datatyperna SQL Och Azure Cognitive Search.

3. Skapa indexeraren genom att ge den ett namn och referera till datakällan och målindexet:

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

En indexerare som skapats på det här sättet har inget schema. Den körs automatiskt en gång när den skapas. Du kan köra den igen när som helst med hjälp av en körningsindexeringsbegäran:

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

Du kan anpassa flera aspekter av indexerarbeteendet, till exempel batchstorlek och hur många dokument som kan hoppas över innan en indexerarkörning misslyckas. Mer information finns i Skapa indexerings-API.

Du kan behöva tillåta att Azure-tjänster ansluter till din databas. Se Ansluta från Azure för anvisningar om hur du gör det.

Om du vill övervaka indexerarstatus och körningshistorik (antalet indexerade objekt, fel osv.) använder du en statusbegäran för indexeraren:

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

Svaret bör se ut ungefär så här:

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

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 i svaret). Mer information om svaret finns i Hämta indexeringsstatus

Köra indexerare enligt ett schema

Du kan också ordna så att indexeraren körs regelbundet enligt ett schema. Det gör du genom att lägga till schemaegenskapen när du skapar eller uppdaterar indexeraren. Exemplet nedan visar en PUT-begäran om att uppdatera indexeraren:

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

Parametern interval krävs. Intervallet avser tiden mellan starten av två på varandra följande indexerarkörningar. Det minsta tillåtna intervallet är 5 minuter. den längsta är en dag. Det måste formateras som ett XSD"dayTimeDuration"-värde (en begränsad delmängd av ett ISO 8601-varaktighetsvärde). Mönstret för detta är: P(nD)(T(nH)(nM)) . Exempel: PT15M var 15:e minut, PT2H varannan timme.

Mer information om hur du definierar indexerarscheman finns i Schemalägga indexerare för Azure Cognitive Search.

Samla in nya, ändrade och borttagna rader

Azure Cognitive Search använder inkrementell indexering för att undvika att behöva indexera om hela tabellen eller vyn varje gång en indexerare körs. Azure Cognitive Search två ändringsidentifieringsprinciper som stöder inkrementell indexering.

SQL Integrerad Ändringsspårning princip

Om din SQL stöder ändringsspårningrekommenderar vi att du använder SQL integrerad Ändringsspårning princip. Det här är den mest effektiva principen. Dessutom kan du Azure Cognitive Search borttagna rader utan att du behöver lägga till en explicit "mjuk borttagning"-kolumn i tabellen.

Krav

• Krav för databasversion:
  • SQL Server 2012 SP3 och senare om du använder SQL Server virtuella Azure-datorer.
  • Azure SQL Database eller SQL Managed Instance.
• Endast tabeller (inga vyer).
• Aktivera ändringsspårning för tabellen i databasen.
• Ingen sammansatt primärnyckel (en primär nyckel som innehåller fler än en kolumn) i tabellen.

Användning

Om du vill använda den här principen skapar eller uppdaterar du datakällan så här:

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

När du SQL en integrerad ändringsspårningsprincip ska du inte ange en separat princip för identifiering av databorttagning – den här principen har inbyggt stöd för att identifiera borttagna rader. Men för att borttagningarna ska identifieras "automagiskt" måste dokumentnyckeln i sökindexet vara samma som primärnyckeln i SQL tabellen.

Princip för ändringsidentifiering för vattenmärke

Den här ändringsidentifieringsprincipen förlitar sig på en "högvattenmärkeskolumn" som samlar in versionen eller tiden då en rad senast uppdaterades. Om du använder en vy måste du använda en princip för vattenmärke. Vattenmärkeskolumnen måste uppfylla följande krav.

Krav

• Alla infogningar anger 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]

Användning

Om du vill använda en princip för vattenmärke skapar eller uppdaterar du datakällan så här:

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

Om du använder en radversionsdatatyp för vattenmärkeskolumnen bör du överväga att använda convertHighWaterMarkToRowVersion konfigurationsinställningen för indexeraren. convertHighWaterMarkToRowVersion gör två saker:

• Använd datatypen rowversion för vattenmärkeskolumnen i indexeraren sql-frågan. Om du använder rätt datatyp förbättras indexerarfrågans prestanda.
• Subtrahera 1 från radversionsvärdet innan indexerarfrågan körs. Vyer med 1 till många kopplingar kan ha rader med duplicerade radversionsvärden. Subtrahering av 1 säkerställer att indexerarfrågan inte missar dessa rader.

Om du vill aktivera den här funktionen skapar eller uppdaterar du indexeraren med följande konfiguration:

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

queryTimeout

Om du stöter på timeout-fel kan du använda indexerarkonfigurationsinställningen för att ange tidsgränsen för frågan till ett värde som är högre än queryTimeout standardvärdet på 5 minuter. Om du till exempel vill ställa in tidsgränsen på 10 minuter skapar eller uppdaterar du indexeraren med följande konfiguration:

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

disableOrderByHighWaterMarkColumn

Du kan också inaktivera ORDER BY [High Water Mark Column] -satsen. Detta rekommenderas dock inte eftersom om indexerarkörningen avbryts av ett fel måste indexeraren bearbeta om alla rader om den körs senare – även om indexeraren redan har bearbetat nästan alla rader när den avbröts. Om du vill ORDER BY inaktivera -satsen använder disableOrderByHighWaterMarkColumn du inställningen i indexerardefinitionen:

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

Princip för borttagning av mjuk borttagning av kolumn

När rader tas bort från källtabellen vill du förmodligen ta bort dessa rader från sökindexet också. Om du använder den SQL policyn för integrerad ändringsspårning, så är detta allt åt dig. Principen för ändringsspårning av vattenmärke hjälper dig dock inte med borttagna rader. Vad bör jag göra?

Om raderna tas bort fysiskt från tabellen kan Azure Cognitive Search kan inte dra slutsatsen att det finns poster som inte längre finns. Du kan dock använda "mjuk borttagning"-metoden 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 hjälp av den kolumnen.

När du använder mjuk borttagning kan du ange principen för mjuk borttagning på följande sätt när du skapar eller uppdaterar datakällan:

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

SoftDeleteMarkerValue måste vara en sträng – använd strängrepresentationen av det faktiska värdet. Om du till exempel har en heltalskolumn där borttagna rader är markerade med värdet 1 använder du "1" . Om du har en BIT-kolumn där borttagna rader är markerade med det booleska värdet true använder du stränglitteralen True true eller .

Mappning mellan SQL och Azure Cognitive Search datatyper

Konfiguration Inställningar

SQL visar flera konfigurationsinställningar:

De här inställningarna används i parameters.configuration objektet i indexerardefinitionen. Om du till exempel vill ange tidsgränsen för frågan till 10 minuter skapar eller uppdaterar du indexeraren med följande konfiguration:

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

Vanliga frågor

F: Kan jag använda Azure SQL med SQL som körs på virtuella IaaS-datorer i Azure?

Ja. Du måste dock tillåta att söktjänsten ansluter till databasen. Mer information finns i Configure a connection from an Azure Cognitive Search indexer to SQL Server on an Azure VM (Konfigurera en anslutning från en indexerare SQL Server en virtuell Azure-dator).

F: Kan jag använda Azure SQL-indexeraren SQL en databas som körs lokalt?

Inte direkt. Vi rekommenderar eller stöder inte en direkt anslutning, eftersom det kräver att du öppnar dina databaser för Internettrafik. Kunder har lyckats med det här scenariot med hjälp av bryggtekniker som Azure Data Factory. Mer information finns i Skicka data till ett Azure Cognitive Search index med hjälp av Azure Data Factory.

F: Kan jag använda Azure SQL indexeraren med andra databaser än SQL Server körs i IaaS på Azure?

Nej. Vi stöder inte det här scenariot eftersom vi inte har testat indexeraren med andra databaser än SQL Server.

F: Kan jag skapa flera indexerare som körs enligt ett schema?

Ja. Dock kan endast en indexerare köras på en nod i taget. Om du behöver köra flera indexerare samtidigt kan du överväga att skala upp söktjänsten till mer än en sökenhet.

F: Påverkar en indexerare min frågearbetsbelastning?

Ja. Indexeraren körs på en av noderna i söktjänsten och nodens resurser delas mellan indexering och betjänar frågetrafik och andra API-begäranden. Om du kör intensiv indexering och frågearbetsbelastningar och stöter på en hög hastighet på 503 fel eller ökande svarstider kan du överväga att skala upp söktjänsten.

F: Kan jag använda en sekundär replik i ett redundanskluster som datakälla?

Det beror på. För fullständig indexering av en tabell eller vy kan du använda en sekundär replik.

För inkrementell indexering Azure Cognitive Search två policyer för ändringsidentifiering: SQL integrerad ändringsspårning och högvattenmärke.

På skrivskyddade repliker SQL Database inte integrerad ändringsspårning. Därför måste du använda principen För vattenmärke.

Vår standardrekommendation är att använda radversionsdatatypen för vattenmärkeskolumnen. Men om du använder rowversion används funktionen MIN_ACTIVE_ROWVERSION , som inte stöds på skrivskyddade repliker. Därför måste du peka indexeraren på en primär replik om du använder rowversion.

Om du försöker använda radversion på en skrivskyddade replik visas följande fel:

"Användning av en radversionskolumn för ändringsspårning stöds inte på sekundära (skrivskyddade) tillgänglighetsrepliker. Uppdatera datakällan och ange en anslutning till den primära tillgänglighetsrepliken. Den aktuella databasens egenskap "Uppdateringsbarhet" är "READ_ONLY".

F: Kan jag använda en alternativ kolumn som inte är radversion för spårning av vattenmärkesändring?

Det rekommenderas inte. Endast radversion tillåter tillförlitlig datasynkronisering. Beroende på din programlogik kan det dock vara säkert om:

• Du kan se till att det inte finns några utestående transaktioner i tabellen som indexeras när indexeraren körs (till exempel sker alla tabelluppdateringar som en batch enligt ett schema och Azure Cognitive Search-indexerarschemat anges för att undvika överlappning med tabelluppdateringsschemat).

• Du gör regelbundet ett fullständigt omindex för att hämta eventuella missade rader.