Prestaties optimaliseren met behulp van in-memory technologieën in Azure SQL Database en Azure SQL Managed Instance

VAN TOEPASSING OP: Azure SQL Database Azure SQL Managed Instance

Met in-memory technologieën kunt u de prestaties van uw toepassing verbeteren en mogelijk de kosten van uw database verlagen.

Wanneer in-memory technologieën worden gebruikt

Met behulp van in-memory technologieën kunt u prestatieverbeteringen bereiken met verschillende workloads:

  • Transactionele (online transactionele verwerking (OLTP)) waarbij de meeste aanvragen kleinere set gegevens lezen of bijwerken (bijvoorbeeld CRUD-bewerkingen).
  • Analyse (online analytical processing (OLAP)) waarbij de meeste query's complexe berekeningen hebben voor de rapportagedoeleinden, met een bepaald aantal query's die gegevens laden en toevoegen aan de bestaande tabellen (zogenaamde bulksgewijs laden) of de gegevens uit de tabellen verwijderen.
  • Gemengde (hybride transactie/analytische verwerking (HTAP)) waarbij zowel OLTP- als OLAP-query's worden uitgevoerd op dezelfde set gegevens.

In-memory technologieën kunnen de prestaties van deze workloads verbeteren door de gegevens die in het geheugen moeten worden verwerkt, te bewaren met behulp van systeemeigen compilatie van de query's of geavanceerde verwerking, zoals batchverwerking en SIMD-instructies die beschikbaar zijn op de onderliggende hardware.

Overzicht

Azure SQL Database en Azure SQL Managed Instance beschikken over de volgende in-memory technologieën:

  • Oltp in het geheugen verhoogt het aantal transacties per seconde en vermindert de latentie voor transactieverwerking. Scenario's die profiteren van In-Memory OLTP zijn: transactieverwerking met hoge doorvoer, zoals handel en gaming, gegevensopname van gebeurtenissen of IoT-apparaten, caching, gegevensbelasting en tijdelijke tabel- en tabelvariabelescenario's.
  • Geclusterde columnstore-indexen verminderen uw opslagvoetafdruk (maximaal 10 keer) en verbeteren de prestaties voor rapportage- en analysequery's. U kunt deze gebruiken met feitentabellen in uw datamarts om meer gegevens in uw database aan te passen en de prestaties te verbeteren. U kunt deze ook gebruiken met historische gegevens in uw operationele database om gegevens te archiveren en er maximaal tien keer query's op uit te voeren.
  • Niet-geclusterde columnstore-indexen voor HTAP helpen u realtime inzicht te krijgen in uw bedrijf door rechtstreeks query's uit te voeren op de operationele database, zonder dat u een duur ETL-proces (extract, transformatie en belasting) hoeft uit te voeren en te wachten tot het datawarehouse is gevuld. Niet-geclusterde columnstore-indexen maken snelle uitvoering van analysequery's op de OLTP-database mogelijk, terwijl de impact op de operationele workload wordt verminderd.
  • Met geoptimaliseerd voor geheugen geoptimaliseerde columnstore-indexen voor HTAP kunt u snelle transactieverwerking uitvoeren en tegelijkertijd analysequery's uitvoeren op dezelfde gegevens.

Zowel columnstore-indexen als In-Memory OLTP maken sinds 2012 en 2014 deel uit van het SQL Server product. Azure SQL Database, Azure SQL Managed Instance en SQL Server dezelfde implementatie van in-memory technologieën delen.

Voordelen van in-memory technologie

Vanwege de efficiëntere query- en transactieverwerking, helpen technologieën in het geheugen u ook om de kosten te verlagen. Doorgaans hoeft u de prijscategorie van de database niet te upgraden om prestatieverbeteringen te behalen. In sommige gevallen kunt u zelfs de prijscategorie verlagen, terwijl u nog steeds prestatieverbeteringen ziet met technologieën in het geheugen.

Door gebruik te maken van In-Memory OLTP, kon Quorum Business Solutions hun workload verdubbelen terwijl DTU's met 70% worden verbeterd. Zie het blogbericht: In-Memory OLTP voor meer informatie.

Notitie

In-memory technologieën zijn beschikbaar in de Premium- en Bedrijfskritiek lagen.

In dit artikel worden aspecten van In-Memory OLTP- en columnstore-indexen beschreven die specifiek zijn voor Azure SQL Database en Azure SQL Managed Instance, en ook voorbeelden:

  • U ziet de impact van deze technologieën op opslag- en gegevensgroottelimieten.
  • U ziet hoe u de verplaatsing van databases beheert die gebruikmaken van deze technologieën tussen de verschillende prijscategorieën.
  • U ziet twee voorbeelden die het gebruik van In-Memory OLTP illustreren, evenals columnstore-indexen.

Zie voor meer informatie over in-memory in SQL Server:

In-Memory OLTP

In-Memory OLTP-technologie biedt extreem snelle bewerkingen voor gegevenstoegang door alle gegevens in het geheugen te bewaren. Het maakt ook gebruik van gespecialiseerde indexen, systeemeigen compilatie van query's en vergrendelingsvrije gegevenstoegang om de prestaties van de OLTP-workload te verbeteren. Er zijn twee manieren om uw In-Memory OLTP-gegevens te ordenen:

  • Voor geheugen geoptimaliseerde rijopslagindeling waarbij elke rij een afzonderlijk geheugenobject is. Dit is een klassieke In-Memory OLTP-indeling die is geoptimaliseerd voor OLTP-workloads met hoge prestaties. Er zijn twee typen tabellen die zijn geoptimaliseerd voor geheugen, die kunnen worden gebruikt in de indeling voor het opslaan van rijenopslag die is geoptimaliseerd voor geheugen:

    • Duurzame tabellen (SCHEMA_AND_DATA) waar de rijen die in het geheugen worden geplaatst, behouden blijven nadat de server opnieuw is opgestart. Dit type tabellen gedraagt zich als een traditionele rijopslagtabel met de extra voordelen van optimalisaties in het geheugen.
    • Niet-duurzame tabellen (SCHEMA_ONLY) waarbij de rijen niet behouden blijven na het opnieuw opstarten. Dit type tabel is ontworpen voor tijdelijke gegevens (bijvoorbeeld vervanging van tijdelijke tabellen) of tabellen waarin u snel gegevens moet laden voordat u deze verplaatst naar een permanente tabel (zogenaamde faseringstabellen).
  • Kolomopslagindeling die is geoptimaliseerd voor geheugen , waarbij gegevens zijn ingedeeld in een kolomindeling. Deze structuur is ontworpen voor HTAP-scenario's waarin u analysequery's moet uitvoeren in dezelfde gegevensstructuur waarin uw OLTP-workload wordt uitgevoerd.

Notitie

In-Memory OLTP-technologie is ontworpen voor de gegevensstructuren die zich volledig in het geheugen kunnen bevinden. Omdat de in-memory gegevens niet naar schijf kunnen worden overgeslagen, moet u ervoor zorgen dat u een database gebruikt die voldoende geheugen heeft. Zie Gegevensgrootte en opslaglimiet voor In-Memory OLTP voor meer informatie.

Er is een programmatische manier om te begrijpen of een bepaalde database ondersteuning biedt voor In-Memory OLTP. U kunt de volgende Transact-SQL-query uitvoeren:

SELECT DatabasePropertyEx(DB_NAME(), 'IsXTPSupported');

Als de query 1 retourneert, wordt In-Memory OLTP ondersteund in deze database. Met de volgende query's worden alle objecten geïdentificeerd die moeten worden verwijderd voordat een database kan worden gedowngraded naar Algemeen, Standard of Basic:

SELECT * FROM sys.tables WHERE is_memory_optimized=1
SELECT * FROM sys.table_types WHERE is_memory_optimized=1
SELECT * FROM sys.sql_modules WHERE uses_native_compilation=1

Gegevensgrootte en opslaglimiet voor In-Memory OLTP

In-Memory OLTP bevat tabellen die zijn geoptimaliseerd voor geheugen, die worden gebruikt voor het opslaan van gebruikersgegevens. Deze tabellen zijn vereist om in het geheugen te passen. Omdat u geheugen rechtstreeks in SQL Database beheert, hebben we het concept van een quotum voor gebruikersgegevens. Dit idee wordt oltp-opslag in het geheugen genoemd.

Elke ondersteunde prijscategorie voor individuele databases en elke prijscategorie voor elastische pools bevat een bepaalde hoeveelheid In-Memory OLTP-opslag.

De volgende items tellen mee voor uw In-Memory OLTP-opslaglimiet:

  • Actieve gebruikersgegevensrijen in tabellen en tabelvariabelen die zijn geoptimaliseerd voor geheugen. Oude rijversies tellen niet mee voor de limiet.
  • Indexen voor tabellen die zijn geoptimaliseerd voor geheugen.
  • Operationele overhead van ALTER TABLE-bewerkingen.

Als u de limiet bereikt, krijgt u een fout zonder quotum en kunt u geen gegevens meer invoegen of bijwerken. Als u deze fout wilt verhelpen, verwijdert u gegevens of verhoogt u de prijscategorie van de database of pool.

Zie Opslag in het geheugen bewaken voor meer informatie over het bewaken van In-Memory OLTP-opslaggebruik en het configureren van waarschuwingen wanneer u bijna de limiet bereikt.

Over elastische pools

Met elastische pools wordt de In-Memory OLTP-opslag gedeeld in alle databases in de pool. Daarom kan het gebruik in de ene database mogelijk van invloed zijn op andere databases. Twee oplossingen hiervoor zijn:

  • Configureer een Max-eDTU of MaxvCore voor databases die lager zijn dan het aantal eDTU's of vCores voor de pool als geheel. Hiermee wordt het In-Memory OLTP-opslaggebruik, in elke database in de groep, maximaal benut tot de grootte die overeenkomt met het aantal eDTU's.
  • Configureer een Min-eDTU of MinvCore dat groter is dan 0. Dit minimum garandeert dat elke database in de pool de hoeveelheid beschikbare In-Memory OLTP-opslag heeft die overeenkomt met de geconfigureerde Min-eDTU of vCore.

Servicelagen van databases wijzigen die gebruikmaken van In-Memory OLTP-technologieën

U kunt uw database of exemplaar altijd upgraden naar een hogere laag, zoals van Algemeen naar Bedrijfskritiek (of Standard naar Premium). De beschikbare functionaliteit en resources nemen alleen toe.

Maar het downgraden van de laag kan een negatieve invloed hebben op uw database. De impact is vooral zichtbaar wanneer u downgradet van Bedrijfskritiek naar Algemeen (of Premium naar Standard of Basic) wanneer uw database In-Memory OLTP-objecten bevat. Tabellen die zijn geoptimaliseerd voor geheugen zijn niet beschikbaar na de downgrade (zelfs als ze zichtbaar blijven). Dezelfde overwegingen zijn van toepassing wanneer u de prijscategorie van een elastische pool verlaagt of een database met in-memory technologieën verplaatst naar een Algemeen, Standard of Basic elastische pool.

Belangrijk

In-Memory OLTP wordt niet ondersteund in de laag Algemeen, Standard of Basic. Daarom is het niet mogelijk om een database met In-Memory OLTP-objecten te verplaatsen naar een van deze lagen.

Voordat u de database downgradet naar Algemeen, Standard of Basic, verwijdert u alle tabellen en tabeltypen die zijn geoptimaliseerd voor geheugen, evenals alle systeemeigen gecompileerde T-SQL-modules.

Resources omlaag schalen in Bedrijfskritiek laag: gegevens in tabellen die zijn geoptimaliseerd voor geheugen, moeten binnen de In-Memory OLTP-opslag passen die is gekoppeld aan de laag van de database of het beheerde exemplaar, of deze is beschikbaar in de elastische pool. Als u probeert de laag omlaag te schalen of de database te verplaatsen naar een pool die onvoldoende beschikbaar is In-Memory OLTP-opslag, mislukt de bewerking.

ColumnStore in het geheugen

In-memory columnstore-technologie stelt u in staat om een grote hoeveelheid gegevens in de tabellen op te slaan en er query's op uit te voeren. Columnstore-technologie maakt gebruik van de indeling voor gegevensopslag op basis van kolommen en batchqueryverwerking om maximaal tien keer de queryprestaties in OLAP-workloads te verkrijgen ten opzichte van traditionele rijgeoriënteerde opslag. U kunt ook tot tien keer meer gegevenscompressie bereiken dan het formaat van de niet-gecomprimeerde gegevensgrootte. Er zijn twee typen columnstore-modellen die u kunt gebruiken om uw gegevens te ordenen:

  • Geclusterde columnstore waarin alle gegevens in de tabel zijn ingedeeld in de kolomindeling. In dit model worden alle rijen in de tabel in kolomindeling geplaatst waarmee de gegevens sterk worden gecomprimeerd en waarmee u snelle analytische query's en rapporten in de tabel kunt uitvoeren. Afhankelijk van de aard van uw gegevens, kan de grootte van uw gegevens 10x-100x afnemen. Geclusterd columnstore-model maakt ook snelle opname van grote hoeveelheden gegevens mogelijk (bulksgewijs laden) omdat grote batches met gegevens groter dan 100.000 rijen worden gecomprimeerd voordat ze op schijf worden opgeslagen. Dit model is een goede keuze voor de klassieke datawarehouse-scenario's.
  • Niet-geclusterde columnstore waarin de gegevens worden opgeslagen in de traditionele rijopslagtabel en er is een index in de columnstore-indeling die wordt gebruikt voor de analytische query's. Met dit model kunt u HTAP (Hybrid Transactional-Analytic Processing) uitvoeren: de mogelijkheid om actieve realtime analyses uit te voeren op een transactionele workload. OLTP-query's worden uitgevoerd op de rijstore-tabel die is geoptimaliseerd voor toegang tot een kleine set rijen, terwijl OLAP-query's worden uitgevoerd op columnstore-index die een betere keuze is voor scans en analyses. De optimalisatiefunctie voor query's kiest dynamisch de indeling rowstore of columnstore op basis van de query. Niet-geclusterde columnstore-indexen verkleinen de grootte van de gegevens niet, omdat de oorspronkelijke gegevensset zonder wijzigingen wordt bewaard in de oorspronkelijke rijopslagtabel. De grootte van de extra columnstore-index moet echter kleiner zijn dan de equivalente B-structuurindex.

Notitie

In-memory columnstore-technologie bewaart alleen de gegevens die nodig zijn voor verwerking in het geheugen, terwijl de gegevens die niet in het geheugen passen, op schijf worden opgeslagen. Daarom kan de hoeveelheid gegevens in columnstore-structuren in het geheugen de hoeveelheid beschikbaar geheugen overschrijden.

Uitgebreide video over de technologie:

Gegevensgrootte en -opslag voor columnstore-indexen

Columnstore-indexen zijn niet vereist om in het geheugen te passen. Daarom is de enige limiet voor de grootte van de indexen de maximale totale databasegrootte, die wordt beschreven in de artikelen over het aankoopmodel op basis van DTU en op vCore gebaseerde aankoopmodellen .

Wanneer u geclusterde columnstore-indexen gebruikt, wordt kolomcompressie gebruikt voor de basistabelopslag. Deze compressie kan de opslagvoetafdruk van uw gebruikersgegevens aanzienlijk verminderen, wat betekent dat u meer gegevens in de database kunt aanpassen. En de compressie kan verder worden verhoogd met kolomarchiveringscompressie. De hoeveelheid compressie die u kunt bereiken, is afhankelijk van de aard van de gegevens, maar 10 keer is de compressie niet ongebruikelijk.

Als u bijvoorbeeld een database hebt met een maximale grootte van 1 terabyte (TB) en u 10 keer de compressie bereikt met behulp van columnstore-indexen, kunt u in totaal 10 TB aan gebruikersgegevens in de database aanpassen.

Wanneer u niet-geclusterde columnstore-indexen gebruikt, wordt de basistabel nog steeds opgeslagen in de traditionele rowstore-indeling. Daarom zijn de opslagbesparingen niet zo belangrijk als bij geclusterde columnstore-indexen. Als u echter een aantal traditionele niet-geclusterde indexen vervangt door één columnstore-index, ziet u nog steeds een algemene besparing in de opslagvoetafdruk voor de tabel.

Servicelagen van databases met Columnstore-indexen wijzigen

Het downgraden van één database naar Basic of Standard is mogelijk niet mogelijk als uw doellaag lager is dan S3. Columnstore-indexen worden alleen ondersteund voor de prijscategorie Bedrijfskritiek/Premium en voor de Standard-laag, S3 en hoger, en niet voor de Basic-laag. Wanneer u uw database downgradet naar een niet-ondersteunde laag of niveau, is de columnstore-index niet meer beschikbaar. Het systeem onderhoudt uw columnstore-index, maar maakt nooit gebruik van de index. Als u later een upgrade uitvoert naar een ondersteunde laag of een ondersteund niveau, is de columnstore-index direct klaar om opnieuw te worden gebruikt.

Als u een geclusterde columnstore-index hebt, is de hele tabel na de downgrade niet meer beschikbaar. Daarom raden we u aan alle geclusterde columnstore-indexen te verwijderen voordat u uw database downgradet naar een niet-ondersteunde laag of niveau.

Notitie

SQL Managed Instance ondersteunt Columnstore-indexen in alle lagen.

Volgende stappen

Aanvullende bronnen

Meer gedetailleerde informatie

Toepassingsontwerp

Hulpprogramma's