Delen via

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

  • Artikel

van toepassing op:Azure SQL Database-

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 realiseren met verschillende workloads:

  • Transactionele (online transactionele verwerking (OLTP)) waarbij de meeste aanvragen kleinere gegevenssets lezen of bijwerken, zoals create/read/update/delete (CRUD)-bewerkingen.
  • Analytische (online analytical processing (OLAP)) waarbij de meeste query's complexe berekeningen hebben voor rapportagedoeleinden, en ook regelmatig geplande processen die laadbewerkingen (of bulklaadoperaties) uitvoeren en/of gegevenswijzigingen naar bestaande tabellen schrijven. OLAP-workloads worden vaak periodiek bijgewerkt vanuit OLTP-workloads.
  • Mixed (Hybrid Transaction/Analytical Processing (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 ondersteunt de volgende technologieën in het geheugen:

  • In-Memory OLTP 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 scenario's voor tabel- en tabelvariabelen.
  • Geclusterde columnstore-indexen uw opslagvoetafdruk (maximaal 10 keer) verminderen en de prestaties voor rapportage- en analysequery's verbeteren. 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 maximaal tien keer meer gegevens te archiveren en er query's op uit te voeren.
  • Niet-geclusterde columnstore-indexen voor HTAP helpen u realtime inzicht te krijgen in uw bedrijf door rechtstreeks een query uit te voeren op de operationele database, zonder dat u een duur ETL-proces (extract, transformatie en belasting) hoeft uit te voeren en wacht tot het datawarehouse is ingevuld. 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 geheugen geoptimaliseerde columnstore-indexen voor HTAP stellen u in staat om snelle transactieverwerking uit te voeren en tegelijkertijd snel analysequery's uit te voeren op dezelfde gegevens.

Columnstore-indexen en In-Memory OLTP zijn in respectievelijk 2012 en 2014 geïntroduceerd in SQL Server. Azure SQL Database, Azure SQL Managed Instance en SQL Server delen dezelfde implementatie van in-memory technologieën.

Notitie

Voor een gedetailleerde stapsgewijze handleiding om de prestatievoordelen van In-Memory OLTP-technologie te demonstreren, met de AdventureWorksLT voorbeelddatabase en ostress.exe, zie In-memory voorbeeld in Azure SQL Database.

Voordelen van in-memory technologie

Vanwege de efficiëntere query- en transactieverwerking, helpen in-memory technologieën u ook om de kosten te verlagen. Doorgaans hoeft u de prijscategorie van de database niet bij te werken om prestatieverbeteringen te behalen. In sommige gevallen kunt u de prijscategorie zelfs verminderen, 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 werkbelasting verdubbelen en tegelijkertijd de DTUs met 70%verbeteren. Zie In-Memory OLTP in Azure SQL Databasevoor meer informatie.

Notitie

In-Memory OLTP is beschikbaar in de Servicelagen Premium (DTU) en Business Critical (vCore) van Azure SQL Database. De Hyperscale-servicelaag ondersteunt een subset van In-Memory OLTP-objecten. Zie Beperkingen van Hyperscalevoor meer informatie.

Columnstore-indexen zijn beschikbaar in alle servicelagen, met uitzondering van de Basic-laag en de Standard-laag wanneer de servicedoelstelling lager is dan S3. Voor meer informatie, zie het wijzigen van servicelagen van databases met columnstore-indexen.

In dit artikel worden aspecten van In-Memory OLTP- en columnstore-indexen beschreven die specifiek zijn voor Azure SQL Database, en bevat ook voorbeelden waarmee u het volgende kunt zien:

  • De impact van deze technologieën op opslag- en gegevensgroottelimieten.
  • Het beheren van de verplaatsing van databases die gebruikmaken van deze technologieën tussen de verschillende prijscategorieën.
  • Een illustratief gebruik van In-Memory OLTP, evenals columnstore-indexen.

Zie voor meer informatie over in-memory technologieën 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 gegevenstoegang zonder vergrendeling om de prestaties van de OLTP-workload te verbeteren. Er zijn twee manieren om uw In-Memory OLTP-gegevens te ordenen:

  • voor geheugen geoptimaliseerde rowstore indeling 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 door het geheugen geoptimaliseerde rowstore-indeling:

    • 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 rowstore-tabel met de extra voordelen van optimalisaties in het geheugen.
    • niet-duurzame tabellen (SCHEMA_ONLY) waarbij de rijen niet behouden blijven na herstart. Dit type tabel is ontworpen voor tijdelijke gegevens (bijvoorbeeld vervanging van tijdelijke tabellen) of tabellen waarin u gegevens snel moet laden voordat u deze verplaatst naar een permanente tabel (zogenaamde faseringstabellen).

  • Geheugen-geoptimaliseerde columnstore-indeling waarin gegevens in een kolomformaat zijn georganiseerd. Deze structuur is ontworpen voor HTAP-scenario's waarbij u analytische query's moet uitvoeren op dezelfde gegevensstructuur waarop 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 de 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.

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. Elke servicedoelstelling heeft een geheugenquotum of limiet voor tabellen die zijn geoptimaliseerd voor geheugen, ook wel bekend als In-Memory OLTP-opslag.

Elke ondersteunde servicedoelstelling voor één database en elke servicedoelstelling voor elastische pools bevat een bepaalde hoeveelheid In-Memory OLTP-opslag:

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

  • Actieve rijen met gebruikersgegevens 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, ontvangt u een fout vanwege quotumoverschrijding en kunt u geen gegevens meer invoegen of bijwerken. Als u deze fout wilt beperken, verwijdert u gegevens of verhoogt u de servicedoelstelling van de database of elastische pool.

Zie Monitor In-Memory In-Memory OLTP-opslagvoor meer informatie over het bewaken van het 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 Max vCore voor databases die lager zijn dan het aantal eDTU's of vCores voor de pool als geheel. Dit maximum beperkt ook proportioneel het In-Memory OLTP-opslaggebruik in elke database in de pool.
  • Configureer een Min eDTU of Min vCore die 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 Min vCore.

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

In-Memory OLTP wordt niet ondersteund in de servicelagen Algemeen gebruik, Standard en Basic van Azure SQL Database. Daarom is het niet mogelijk om een database met In-Memory OLTP-objecten te schalen naar een van deze lagen. Als u een database wilt schalen naar een van deze servicelagen, verwijdert u alle tabellen en tabeltypen die zijn geoptimaliseerd voor geheugen, evenals alle systeemeigen gecompileerde T-SQL-modules, of converteert u deze naar schijfobjecten en reguliere T-SQL-modules.

Wanneer u een bedrijfskritieke database of een Premium-database omlaag schaalt, moeten gegevens in de tabellen die zijn geoptimaliseerd voor geheugen, binnen de In-Memory OLTP-opslag passen die beschikbaar is in de doelservicedoelstelling van de database of elastische pool. Als u probeert de database of elastische pool omlaag te schalen, of een database naar een elastische pool te verplaatsen, en de doelenservicedoelstelling heeft niet genoeg beschikbare In-Memory OLTP-opslag, mislukt de bewerking.

Bepalen of In-Memory OLTP-objecten bestaan

Er is een programmatische manier om te bepalen 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 1retourneert, wordt In-Memory OLTP ondersteund in deze database.

De volgende query's identificeren alle objecten die moeten worden verwijderd voordat een database kan worden geschaald naar de Servicelaag Hyperscale, Algemeen gebruik, 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;

In-geheugen kolomopslag

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 kolomgebaseerde gegevensopslagindeling en batchqueryverwerking om maximaal 10 keer de queryprestaties in OLAP-workloads te verkrijgen ten opzichte van traditionele rijgeoriënteerde opslag. U kunt ook tot 10 keer meer gegevenscompressie bereiken dan de niet-gecomprimeerde gegevensgrootte.

Er zijn twee typen columnstore-indexen die u kunt gebruiken om uw gegevens te ordenen:

  • Gegroepeerde columnstore waar alle gegevens in de tabel zijn geordend in de kolomindeling. In dit type index 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. Geclusterde columnstore-indexen maken 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 type index is een goede keuze voor de klassieke datawarehouse-scenario's.
  • niet-geclusterde columnstore waar de gegevens worden opgeslagen in de traditionele rowstore-tabel en er een extra index is in de columnstore-indeling die wordt gebruikt voor de analytische query's. Dit type index maakt Hybrid Transactional-Analytic Processing (HTAP) mogelijk: de mogelijkheid om snelle realtime analyses uit te voeren op een transactionele workload. OLTP-query's worden uitgevoerd op een rowstore-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 queryoptimalisatie kiest dynamisch de indeling rowstore of columnstore op basis van de query. Niet-geclusterde columnstore-indexen verkleinen niet de grootte van de gegevens, omdat de oorspronkelijke gegevensset zonder wijzigingen wordt bewaard in de oorspronkelijke tabel rowstore. De grootte van de extra columnstore-index is echter vele malen kleiner dan de equivalente B-tree-index.

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 de hoeveelheid beschikbaar geheugen overschrijden.

Gegevensgrootte en -opslag voor columnstore-indexen

Columnstore-indexen hoeven niet volledig in het geheugen te passen. Daarom is de enige limiet voor de grootte van de indexen de maximale totale databasegrootte, zoals beschreven in de artikelen met de titel DTU-gebaseerd aankoopmodel en vCore-gebaseerd aankoopmodel.

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. De compressieverhouding kan verder worden verhoogd met kolomarchivering. De hoeveelheid compressie die u kunt bereiken, is afhankelijk van de aard van de gegevens, maar 10 keer is de compressie niet ongewoon.

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 veel traditionele niet-geclusterde indexen vervangt door één columnstore-index, kunt u nog steeds een algemene besparing in de opslagvoetafdruk voor de tabel zien. U kunt ook rowstore gegevenscompressie gebruiken voor de basistabel.

Servicelagen van databases met columnstore-indexen wijzigen

Als u het DTU-aankoopmodel gebruikt en uw database columnstore-indexen bevat, werkt uw toepassing mogelijk niet meer als u de database onder de S3-servicedoelstelling schaalt. Columnstore-indexen worden alleen ondersteund in de servicelagen Hyperscale, Bedrijfskritiek en Premium, evenals in de Standard-servicelaag als u S3 en hoger gebruikt. Columnstore-indexen worden niet ondersteund in de Basic-servicelaag. Wanneer u uw database schaalt naar een niet-ondersteunde servicelaag of servicedoelstelling, is de columnstore-index niet meer beschikbaar. Het systeem onderhoudt de index wanneer u DML-instructies uitvoert, maar gebruikt nooit de index. Als u later terugschaalt naar een ondersteunde servicelaag of servicedoelstelling, is uw columnstore-index onmiddellijk gereed om opnieuw te worden gebruikt.

Als u een geclusterde columnstore-index hebt, is de hele tabel niet meer beschikbaar als de database wordt geschaald naar een niet-ondersteunde servicelaag of servicedoelstelling. Laat alle gegroepeerde columnstore-indexen vallen en vervang ze door rowstore-geclusterde indexen of heaps voordat de schaalbewerking wordt uitgevoerd.

Verwante inhoud