Gegevens uit Azure-SQL

In dit artikel wordt beschreven hoe u een Azure SQL configureert om inhoud te extraheren en deze doorzoekbaar te maken in Azure Cognitive Search. Deze werkstroom maakt een zoekindex op Azure Cognitive Search en laadt deze met bestaande inhoud die is geëxtraheerd uit Azure SQL Database en Azure SQL beheerde exemplaren.

In dit artikel worden de mechanismen voor het gebruik van indexeringsprogramma's beschreven, maar worden ook functies beschreven die alleen beschikbaar zijn met Azure SQL Database of SQL Managed Instance (bijvoorbeeld geïntegreerde tracering van veranderingen).

U kunt een Azure SQL indexer instellen met behulp van een van deze clients:

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

In dit artikel worden de REST API's gebruikt.

Vereisten

• Gegevens zijn afkomstig uit één tabel of weergave. Als de gegevens zijn verspreid over meerdere tabellen, kunt u één weergave van de gegevens maken. Een nadeel van het gebruik van de weergave is dat u de geïntegreerde wijzigingsdetectie SQL Server index niet kunt vernieuwen met incrementele wijzigingen. Zie Het vastleggen van gewijzigde en verwijderde rijen hieronder voor meer informatie.

• Gegevenstypen moeten compatibel zijn. De meeste maar niet alle SQL worden ondersteund in een zoekindex. Zie Toewijzingsgegevenstypen voor een lijst.

• Verbindingen met een SQL beheerd exemplaar moeten via een openbaar eindpunt zijn. Zie Indexer-verbindingen via een openbaar eindpunt voor meer informatie.

• Voor verbindingen met SQL Server virtuele Azure-machine is een handmatige set van een beveiligingscertificaat vereist. Zie Indexer connections to a SQL Server on an Azure VM (Indexer-verbindingen met een SQL Server op een Azure-VM) voor meer informatie.

Realtime gegevenssynchronisatie mag geen toepassingsvereiste zijn. Een indexer kan uw tabel ten zeerste elke vijf minuten opnieuw indexeren. Als uw gegevens regelmatig worden gewijzigd en deze wijzigingen binnen enkele seconden of enkele minuten moeten worden doorgevoerd in de index, raden we u aan de REST API- of .NET SDK te gebruiken om bijgewerkte rijen rechtstreeks te pushen.

Incrementele indexering is mogelijk. Als u een grote gegevensset hebt en van plan bent om de indexer volgens een schema uit te voeren, moeten Azure Cognitive Search in staat zijn om op efficiënte wijze nieuwe, gewijzigde of verwijderde rijen te identificeren. Niet-incrementele indexering is alleen toegestaan als u op aanvraag indexeert (niet volgens schema) of minder dan 100.000 rijen indexeert. Zie Het vastleggen van gewijzigde en verwijderde rijen hieronder voor meer informatie.

Azure Cognitive Search ondersteunt SQL Server verificatie, waarbij de gebruikersnaam en het wachtwoord worden opgegeven op de connection string. U kunt ook een beheerde identiteit instellen en Azure-rollen gebruiken om referenties voor de verbinding weg te laten. Zie Een indexeringsverbinding instellenmet behulp van een beheerde identiteit voor meer informatie.

Een Azure SQL Indexer maken

1. Maak de gegevensbron:

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

   De connection string kunnen een van de onderstaande indelingen volgen:

   1. U kunt de connection string op de Azure Portal; gebruik de ADO.NET connection string optie .
   2. Een beheerde identiteit connection string die geen accountsleutel met de volgende indeling bevat: 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; . Als u deze connection string, volgt u de instructies voor Het instellen van een indexeringsverbinding met een Azure SQL Database met behulp van een beheerde identiteit.

2. Maak de Azure Cognitive Search index als u er nog geen hebt. U kunt een index maken met behulp van de portal of de Api voor het maken van indexen. Zorg ervoor dat het schema van uw doelindex compatibel is met het schema van de brontabel. Zie toewijzing tussen SQL en Azure Cognitive search-gegevenstypen.

3. Maak de indexer door deze een naam te geven en te verwijzen naar de gegevensbron en doelindex:

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

Een indexer die op deze manier is gemaakt, heeft geen planning. Deze wordt automatisch één keer uitgevoerd wanneer deze wordt gemaakt. U kunt deze op elk moment opnieuw uitvoeren met behulp van een indexeringsaanvraag voor uitvoeren:

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

U kunt verschillende aspecten van het gedrag van de indexer aanpassen, zoals de batchgrootte en het aantal documenten dat kan worden overgeslagen voordat de uitvoering van een indexer mislukt. Zie Create Indexer API (Indexer-API maken) voor meer informatie.

Mogelijk moet u Toestaan dat Azure-services verbinding maken met uw database. Zie Verbinding maken vanuit Azure voor instructies over hoe u dat doet.

Als u de status en uitvoeringsgeschiedenis van de indexer wilt controleren (aantal geïndexeerde items, fouten, enzovoort), gebruikt u een statusaanvraag voor de indexer:

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

Het antwoord moet er ongeveer als volgt uitzien:

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

De uitvoeringsgeschiedenis bevat maximaal 50 van de meest recent voltooide uitvoeringen, die in omgekeerde chronologische volgorde worden gesorteerd (zodat de meest recente uitvoering het eerst in het antwoord komt). Meer informatie over het antwoord vindt u in Indexerstatus verkrijgen

Indexeren op basis van een schema uitvoeren

U kunt de indexeringsmanager ook regelmatig volgens een schema laten uitvoeren. Voeg hiervoor de eigenschap schedule toe bij het maken of bijwerken van de indexer. In het onderstaande voorbeeld ziet u een PUT-aanvraag voor het bijwerken van de indexer:

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

De intervalparameter is vereist. Het interval verwijst naar de tijd tussen het begin van twee opeenvolgende indexeringsuitvoeringen. Het kleinste toegestane interval is 5 minuten; de langste is één dag. Deze moet worden opgemaakt als een XSD dayTimeDuration-waarde (een beperkte subset van een ISO 8601-duurwaarde). Het patroon hiervoor is: P(nD)(T(nH)(nM)) . Voorbeelden: PT15M voor elke 15 minuten, PT2H voor elke 2 uur.

Zie How to schedule indexers for Azure Cognitive Search voor meer informatie over het definiëren van indexeringsschema'Azure Cognitive Search.

Nieuwe, gewijzigde en verwijderde rijen vastleggen

Azure Cognitive Search maakt gebruik van incrementele indexering om te voorkomen dat de hele tabel opnieuw moet worden geïndexeerd of moet worden bekeken telkens als een indexer wordt uitgevoerd. Azure Cognitive Search biedt twee beleidsregels voor wijzigingsdetectie ter ondersteuning van incrementeel indexeren.

SQL Geïntegreerd Wijzigingen bijhouden beleid

Als uw SQL database ondersteuningbiedt voor het bijhouden van wijzigen, raden we u aan SQL Integrated Wijzigingen bijhouden Policy te gebruiken. Dit is het meest efficiënte beleid. Bovendien kunt u Azure Cognitive Search verwijderde rijen identificeren zonder dat u een expliciete kolom voor 'soft delete' aan uw tabel moet toevoegen.

Vereisten

• Vereisten voor de databaseversie:
  • SQL Server 2012 SP3 en hoger, als u een SQL Server azure-VM's gebruikt.
  • Azure SQL Database of SQL Managed Instance.
• Alleen tabellen (geen weergaven).
• Schakel in de database het bijhouden van de gegevens voor de tabel in.
• Geen samengestelde primaire sleutel (een primaire sleutel met meer dan één kolom) in de tabel.

Gebruik

Als u dit beleid wilt gebruiken, maakt of updatet u uw gegevensbron als de volgende:

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

Wanneer u SQL beleid voor het bijhouden van geïntegreerde wijzigingsvolgsystemen gebruikt, moet u geen afzonderlijk detectiebeleid voor het verwijderen van gegevens opgeven. Dit beleid biedt ingebouwde ondersteuning voor het identificeren van verwijderde rijen. De documentsleutel in uw zoekindex moet echter gelijk zijn aan de primaire sleutel in de tabel SQL verwijderd om de verwijderde items automatisch te kunnen detecteren.

Beleid voor wijzigingsdetectie van bovengrens

Dit beleid voor wijzigingsdetectie is afhankelijk van een bovengrenskolom waarin de versie of tijd wordt vastleggen waarop een rij voor het laatst is bijgewerkt. Als u een weergave gebruikt, moet u een boven watermerkbeleid gebruiken. De boven watermerkkolom moet voldoen aan de volgende vereisten.

Vereisten

• Alle invoegingen geven een waarde voor de kolom op.
• Alle updates voor een item wijzigen ook de waarde van de kolom.
• De waarde van deze kolom neemt toe bij elke invoeging of update.
• Query's met de volgende WHERE- en ORDER BY-component kunnen efficiënt worden uitgevoerd: WHERE [High Water Mark Column] > [Current High Water Mark Value] ORDER BY [High Water Mark Column]

Gebruik

Als u een beleid voor boven water wilt gebruiken, maakt of updatet u uw gegevensbron als de volgende:

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

Als u een rowversion-gegevenstype gebruikt voor de bovenkolom, kunt u overwegen de convertHighWaterMarkToRowVersion configuratie-instelling van de indexeerserver te gebruiken. convertHighWaterMarkToRowVersion doet twee dingen:

• Gebruik het gegevenstype rowversion voor de kolom boven water in de sql-query van de indexeerfunctie. Door het juiste gegevenstype te gebruiken, worden de queryprestaties van de indexer verbeterd.
• Trekt 1 af van de rowversion-waarde voordat de indexerquery wordt uitgevoerd. Weergaven met 1 tot veel joins kunnen rijen met dubbele rowversion-waarden bevatten. Door 1 af te trekken, worden deze rijen niet gemist door de indexerquery.

Als u deze functie wilt inschakelen, maakt of werkt u de indexer bij met de volgende configuratie:

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

queryTimeout

Als er time-outfouten optreden, kunt u de configuratie-instelling van de indexer gebruiken om de time-out van de query in te stellen op een waarde die hoger is dan de queryTimeout standaard time-out van vijf minuten. Als u de time-out bijvoorbeeld wilt instellen op 10 minuten, maakt of updatet u de indexer met de volgende configuratie:

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

disableOrderByHighWaterMarkColumn

U kunt de -component ook ORDER BY [High Water Mark Column] uitschakelen. Dit wordt echter niet aanbevolen, omdat als de uitvoering van de indexer wordt onderbroken door een fout, de indexer alle rijen opnieuw moet verwerken als deze later wordt uitgevoerd, zelfs als de indexer bijna alle rijen al heeft verwerkt op het moment dat deze werd onderbroken. Als u de component ORDER BY wilt uitschakelen, gebruikt u disableOrderByHighWaterMarkColumn de instelling in de definitie van de indexeringsdefinitie:

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

Detectiebeleid voor het verwijderen van kolommen voor soft delete

Wanneer rijen uit de brontabel worden verwijderd, wilt u deze rijen waarschijnlijk ook uit de zoekindex verwijderen. Als u het geïntegreerde SQL voor het bijhouden van veranderingen gebruikt, wordt dit voor u verzorgd. Het beleid voor het bijhouden van de boven watermerkwijziging helpt u echter niet bij verwijderde rijen. Wat u moet doen?

Als de rijen fysiek uit de tabel worden verwijderd, kan Azure Cognitive Search de aanwezigheid van records die niet meer bestaan, afleiden. U kunt echter de techniek 'soft-delete' gebruiken om rijen logisch te verwijderen zonder ze uit de tabel te verwijderen. Voeg een kolom toe aan uw tabel of bekijk en markeer rijen als verwijderd met behulp van die kolom.

Wanneer u de techniek voor het verwijderen van de soft-delete gebruikt, kunt u het beleid voor het verwijderen van de gegevens als volgt opgeven bij het maken of bijwerken van de gegevensbron:

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

SoftDeleteMarkerValue moet een tekenreeks zijn. Gebruik de tekenreeksweergave van uw werkelijke waarde. Als u bijvoorbeeld een kolom met gehele getallen hebt waarin verwijderde rijen zijn gemarkeerd met de waarde 1, gebruikt u "1" . Als u een BIT-kolom hebt waarin verwijderde rijen zijn gemarkeerd met de booleaanse waarde true, gebruikt u de letterlijke tekenreeks of . Het geval True true maakt niet uit.

Toewijzing tussen SQL en Azure Cognitive Search gegevenstypen

Configuratie-instellingen

SQL indexer maakt verschillende configuratie-instellingen weer:

Deze instellingen worden gebruikt in het parameters.configuration -object in de definitie van de indexeringsdefinitie. Als u de time-out van de query bijvoorbeeld wilt instellen op 10 minuten, maakt of updatet u de indexer met de volgende configuratie:

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

Veelgestelde vragen

V: Kan ik azure SQL indexer gebruiken met SQL databases die worden uitgevoerd op IaaS-VM's in Azure?

Ja. U moet uw zoekservice echter toestaan verbinding te maken met uw database. Zie Configure a connection from an Azure Cognitive Search indexer to SQL Server on an Azure VM (Een verbinding configureren vanaf een Azure Cognitive Search-indexer naar een SQL Server azure-VM) voor meer informatie.

V: Kan ik Azure SQL indexer gebruiken met SQL databases die on-premises worden uitgevoerd?

Niet rechtstreeks. We raden u aan of bieden geen ondersteuning voor een directe verbinding, omdat u dan uw databases moet openen voor internetverkeer. Klanten zijn geslaagd met dit scenario met behulp van brugtechnologieën zoals Azure Data Factory. Zie Gegevens pushen naar een Azure Cognitive Search index met behulp van Azure Data Factory.

V: Kan ik Azure SQL indexer gebruiken met andere databases dan SQL Server uitgevoerd in IaaS op Azure?

Nee. Dit scenario wordt niet ondersteund, omdat we de indexer niet hebben getest met andere databases dan SQL Server.

V: Kan ik meerdere indexeringen maken die volgens een schema worden uitgevoerd?

Ja. Er kan echter slechts één indexer tegelijk worden uitgevoerd op één knooppunt. Als u meerdere indexeren tegelijk wilt uitvoeren, kunt u uw zoekservice omhoog schalen naar meer dan één zoekeenheid.

V: Is het uitvoeren van een indexeringsfunctie van invloed op mijn querywerkbelasting?

Ja. Indexer wordt uitgevoerd op een van de knooppunten in uw zoekservice en de resources van dat knooppunt worden gedeeld tussen het indexeren en verwerken van queryverkeer en andere API-aanvragen. Als u intensieve indexering uitvoert en workloads opvraagt en een hoge snelheid van 503 fouten ondervindt of als de reactietijden toenemen, kunt u overwegen om uw zoekservice op te schalen.

V: Kan ik een secundaire replica in een failovercluster gebruiken als gegevensbron?

Dat hangt ervan af. Voor het volledig indexeren van een tabel of weergave kunt u een secundaire replica gebruiken.

Voor incrementele indexering ondersteunt Azure Cognitive Search twee beleidsregels voor wijzigingsdetectie: SQL geïntegreerde tracering van veranderingen en Bovengrens.

Op alleen-lezen replica's biedt SQL Database geen ondersteuning voor geïntegreerde tracering van veranderingen. Daarom moet u het beleid Voor boven water gebruiken.

Onze standaardaanbeveling is om het gegevenstype rowversion te gebruiken voor de boven watermerkkolom. Het gebruik van rowversion is echter afhankelijk van de MIN_ACTIVE_ROWVERSION functie , die niet wordt ondersteund op alleen-lezen replica's. Daarom moet u de indexer naar een primaire replica laten wijzen als u rowversion gebruikt.

Als u rowversion probeert te gebruiken op een alleen-lezen replica, ziet u de volgende fout:

'Het gebruik van een rowversion-kolom voor het bijhouden van veranderingen wordt niet ondersteund op secundaire (alleen-lezen) beschikbaarheidsreplica's. Werk de gegevensbron bij en geef een verbinding op met de primaire beschikbaarheidsreplica. De huidige eigenschap 'Updateability' van de database is READ_ONLY'.

V: Kan ik een alternatieve, niet-rowversion-kolom gebruiken voor het bijhouden van boven watermerkwijziging?

Dit wordt niet aanbevolen. Alleen rowversion maakt betrouwbare gegevenssynchronisatie mogelijk. Afhankelijk van uw toepassingslogica kan het echter veilig zijn als:

• U kunt ervoor zorgen dat wanneer de indexer wordt uitgevoerd, er geen openstaande transacties zijn in de tabel die wordt geïndexeerd (alle tabelupdates worden bijvoorbeeld uitgevoerd als een batch volgens een schema en de Azure Cognitive Search-indexeringsplanning is ingesteld om overlapping met het schema voor tabelupdates te voorkomen).

• U kunt periodiek een volledige herindex maken om eventuele gemiste rijen op te halen.