Dela via

Optimera prestanda med hjälp av minnesintern teknik i Azure SQL Database

  • Artikel

gäller för:Azure SQL Database

Med minnesintern teknik kan du förbättra programmets prestanda och eventuellt minska kostnaderna för databasen.

När du ska använda minnesintern teknik

Genom att använda minnesintern teknik kan du uppnå prestandaförbättringar med olika arbetsbelastningar:

  • Transactional (online transactional processing (OLTP)) där de flesta begäranden läser eller uppdaterar en mindre datamängd, till exempel CRUD-operationer (create/read/update/delete).
  • Analytisk (onlineanalytisk bearbetning (OLAP)) där de flesta frågorna har komplexa beräkningar för rapporteringssyfte och även regelbundet schemalagda processer som utför belastningsåtgärder (eller massinläsningsoperationer) och/eller skriver dataändringar till befintliga tabeller. OLAP-arbetsbelastningar uppdateras ofta regelbundet från OLTP-arbetsbelastningar.
  • Mixed (hybridtransaktions-/analysbearbetning (HTAP)) där både OLTP- och OLAP-frågor körs på samma datauppsättning.

Minnesintern teknik kan förbättra prestandan för dessa arbetsbelastningar genom att behålla de data som ska bearbetas till minnet, använda intern kompilering av frågorna eller avancerad bearbetning, till exempel batchbearbetning och SIMD-instruktioner som är tillgängliga på den underliggande maskinvaran.

Överblick

Azure SQL Database stöder följande minnesinterna tekniker:

  • In-Memory OLTP ökar antalet transaktioner per sekund och minskar svarstiden för transaktionsbearbetning. Scenarier som drar nytta av In-Memory OLTP är: transaktionsbearbetning med högt dataflöde, till exempel handel och spel, datainmatning från händelser eller IoT-enheter, cachelagring, datainläsning och tillfälliga scenarier för tabell- och tabellvariabler.
  • Kolumnlagringsindex minskar lagringsbehovet (upp till 10 gånger) och förbättrar prestanda för rapporterings- och analysfrågor. Du kan använda den med faktatabeller i dina datakällor för att få plats med mer data i databasen och förbättra prestandan. Du kan också använda den med historiska data i din driftdatabas för att arkivera och kunna fråga upp till 10 gånger mer data.
  • Icke-klustrade kolumnlagringsindex för HTAP hjälper dig att få insikter i realtid i ditt företag genom att anropa den operativa databasen direkt, utan att behöva köra en dyr ETL-process (extrahering, transformering och inläsning) och vänta tills datalagret fylls i. Icke-klustrade kolumnlagringsindex möjliggör snabb exekvering av analytiska frågor i OLTP-databasen, samtidigt som påverkan på den operativa arbetsbelastningen minskar.
  • minnesoptimerade grupperade kolumnlagringsindex för HTAP kan du utföra snabb transaktionsbearbetning och samtidigt köra analysfrågor mycket snabbt på samma data.

Kolumnlagringsindex och In-Memory OLTP introducerades till SQL Server 2012 respektive 2014. Azure SQL Database, Azure SQL Managed Instance och SQL Server delar samma implementering av minnesintern teknik.

Not

En detaljerad steg-för-steg handledning för att demonstrera prestandafördelarna med In-Memory OLTP-teknik, med hjälp av AdventureWorksLT exempeldatabas och ostress.exe, finns i Minnesinternt exempel i Azure SQL Database.

Fördelar med minnesintern teknik

Tack vare den effektivare fråge- och transaktionsbearbetningen hjälper minnesintern teknik dig också att minska kostnaderna. Du behöver vanligtvis inte uppgradera prisnivån för databasen för att uppnå prestandavinster. I vissa fall kanske du till och med kan minska prisnivån, samtidigt som du ser prestandaförbättringar med minnesintern teknik.

Med hjälp av In-Memory OLTP kunde Quorum Business Solutions fördubbla sin arbetsbelastning samtidigt som DTU:er förbättrades med 70%. Mer information finns i In-Memory OLTP i Azure SQL Database.

Anteckning

In-Memory OLTP är tillgängligt på tjänstnivåerna Premium (DTU) och Affärskritisk (vCore) i Azure SQL Database. Tjänstnivån Hyperskala stöder en delmängd av In-Memory OLTP-objekt. Mer information finns i Hyperskalabegränsningar.

Kolumnlagringsindex är tillgängliga på alla tjänstnivåer, förutom Basic-nivån, och på Standard-nivån när tjänstemålet är under S3. Mer information finns i Ändra tjänstnivåer för databaser som innehåller kolumnlagringsindex.

Den här artikeln beskriver aspekter av In-Memory OLTP- och columnstore-index som är specifika för Azure SQL Database och innehåller även exempel som du kan se:

  • Effekten av dessa tekniker på lagrings- och datastorleksgränser.
  • Så här hanterar du förflyttningen av databaser som använder dessa tekniker mellan de olika prisnivåerna.
  • En illustrativ användning av In-Memory OLTP samt kolumnlagringsindex.

Mer information om minnesintern teknik i SQL Server finns i:

In-Memory OLTP

In-Memory OLTP-teknik ger extremt snabba dataåtkomståtgärder genom att hålla alla data i minnet. Den använder också specialiserade index, intern kompilering av frågor och spärrfri dataåtkomst för att förbättra prestanda för OLTP-arbetsbelastningen. Det finns två sätt att organisera dina In-Memory OLTP-data:

  • Minnesoptimerat radlager-format där varje rad är ett enskilt minnesobjekt. Det här är ett klassiskt In-Memory OLTP-format som är optimerat för OLTP-arbetsbelastningar med höga prestanda. Det finns två typer av minnesoptimerade tabeller som kan användas i det minnesoptimerade radlagringsformatet:

    • Durable-tabeller (SCHEMA_AND_DATA) där raderna som placeras i minnet bevaras efter omstart av servern. Den här typen av tabeller fungerar som en traditionell radlagringstabell med de ytterligare fördelarna med minnesintern optimering.
    • Icke-lagringsbara tabeller (SCHEMA_ONLY) där raderna inte bevaras efter omstart. Den här typen av tabell är utformad för tillfälliga data (till exempel ersättning av temporära tabeller) eller tabeller där du snabbt behöver läsa in data innan du flyttar dem till en beständig tabell (så kallade mellanlagringstabeller).

  • minnesoptimerad kolumnlagring format där data ordnas i ett kolumnformat. Den här strukturen är utformad för HTAP-scenarier där du behöver köra analysfrågor på samma datastruktur där OLTP-arbetsbelastningen körs.

Anteckning

In-Memory OLTP-teknik är utformad för de datastrukturer som helt kan finnas i minnet. Eftersom minnesinterna data inte kan avlastas till disken kontrollerar du att du använder en databas som har tillräckligt med minne. Mer information finns i Datastorlek och lagringsgräns för In-Memory OLTP-.

Datastorlek och lagringsgräns för In-Memory OLTP

In-Memory OLTP innehåller minnesoptimerade tabeller som används för att lagra användardata. Dessa tabeller krävs för att få plats i minnet. Varje tjänstmål har en minneskvot eller ett tak för minnesoptimerade tabeller, som kallas In-Memory OLTP-lagring.

Varje stödd serviceobjektiv för en enskild databastjänst och varje serviceobjektiv för en elastisk pool inkluderar en viss mängd In-Memory OLTP-lagringsutrymme.

Följande objekt räknas mot ditt In-Memory OLTP-lagringstak:

  • Aktiva användardatarader i minnesoptimerade tabeller och tabellvariabler. Gamla radversioner räknas inte mot taket.
  • Index på minnesoptimerade tabeller.
  • Driftkostnader för ALTER TABLE-åtgärder.

Om du når taket får du ett fel på grund av kvotöverskridning, och du kan inte längre infoga eller uppdatera data. Du kan åtgärda det här felet genom att ta bort data eller öka tjänstmålet för databasen eller den elastiska poolen.

För mer information om övervakning av In-Memory OLTP-lagringsanvändning och konfigurering av aviseringar när du nästan når gränsen, se Övervaka In-Memory OLTP-lagring.

Om elastiska pooler

Med elastiska pooler delas In-Memory OLTP-lagring över alla databaser i poolen. Därför kan användningen i en databas potentiellt påverka andra databaser. Två åtgärder för detta är:

  • Konfigurera en Max eDTU eller Max vCore för databaser till ett värde som är lägre än antalet eDTU eller vCores för hela poolen. Det här maxvärdet omfattar även In-Memory OLTP-lagringsanvändning i valfri databas i poolen proportionellt.
  • Konfigurera en Min eDTU eller Min vCore som är större än 0. Detta minimikrav garanterar att varje databas i poolen har den mängd tillgänglig In-Memory OLTP-lagring som motsvarar den konfigurerade Min eDTU eller Min vCore.

Ändra tjänstnivåer för databaser som använder In-Memory OLTP-tekniker

In-Memory OLTP stöds inte på tjänstnivåerna Generell användning, Standard och Basic i Azure SQL Database. Därför går det inte att skala en databas som har någon In-Memory OLTP-objekt till någon av dessa nivåer. Om du vill skala en databas till någon av dessa tjänstnivåer tar du bort alla minnesoptimerade tabeller och tabelltyper samt alla internt kompilerade T-SQL-moduler eller konverterar dem till diskbaserade objekt och vanliga T-SQL-moduler.

När du skalar ned en affärskritisk databas eller en Premium-databas måste data i de minnesoptimerade tabellerna passa in i den In-Memory OLTP-lagring som är tillgänglig i måltjänstmålet för databasen eller den elastiska poolen. Om du försöker skala ned databasen eller den elastiska poolen eller flytta en databas till en elastisk pool, och måltjänstmålet inte har tillräckligt med tillgängligt In-Memory OLTP-lagring, misslyckas åtgärden.

Avgöra om In-Memory OLTP-objekt finns

Det finns ett programmatiskt sätt att ta reda på om en viss databas stöder In-Memory OLTP. Du kan köra följande Transact-SQL fråga:

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

Om frågan returnerar 1stöds In-Memory OLTP i den här databasen.

Följande frågor identifierar alla objekt som behöver tas bort innan en databas kan skalas till tjänstnivån Hyperskala, Generell användning, Standard eller 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;

Minnesinternt kolumnarkiv

Med den minnesinterna kolumnlagringstekniken kan du lagra och utföra frågor mot en stor mängd data i tabeller. Columnstore-tekniken använder kolumnbaserat datalagringsformat och batchfrågebearbetning för att få upp till 10 gånger frågeprestandan i OLAP-arbetsbelastningar jämfört med traditionell radorienterad lagring. Du kan också uppnå en datakomprimering upp till 10 gånger av den okomprimerade datastorleken.

Det finns två typer av kolumnlagringsindex som du kan använda för att organisera dina data:

  • Grupperat kolumnarkiv där alla data i tabellen är ordnade i kolumnformat. I den här typen av index placeras alla rader i tabellen i kolumnformat som komprimerar data mycket och gör att du kan köra snabba analysfrågor och rapporter i tabellen. Beroende på typen av data kan storleken på dina data minskas 10x-100x. Grupperade kolumnlagringsindex möjliggör också snabb inmatning av stora mängder data (massinläsning) eftersom stora mängder data som är större än 100 000 rader komprimeras innan de lagras på disk. Den här typen av index är ett bra val för de klassiska informationslagerscenarierna.
  • icke-klustrat kolumnarkiv där data lagras i en traditionell radlagringstabell och det finns ytterligare ett index i kolumnlagringsformatet som används för analysfrågorna. Den här typen av index möjliggör Hybrid Transactional-Analytic Processing (HTAP): möjligheten att köra snabba realtidsanalyser på en transaktionsarbetsbelastning. OLTP-frågor körs i radlagringstabellen som är optimerad för åtkomst till en liten uppsättning rader, medan OLAP-frågor körs på kolumnlagringsindex som är bättre val för genomsökningar och analys. Frågeoptimeraren väljer dynamiskt radlagrings- eller kolumnlagringsformat baserat på frågan. Icke-grupperade kolumnlagringsindex minskar inte datastorleken eftersom den ursprungliga datauppsättningen sparas i den ursprungliga radlagringstabellen utan någon ändring. Storleken på det ytterligare kolumnlagringsindexet är dock storleksordningen mindre än motsvarande B-trädindex.

Not

Minnesintern kolumnlagringsteknik behåller endast de data som behövs för bearbetning i minnet, medan de data som inte får plats i minnet lagras på disken. Därför kan mängden data i kolumnlagringsstrukturer överskrida mängden tillgängligt minne.

Datastorlek och lagring för kolumnlagringsindex

Kolumnlagringsindex behöver inte rymmas helt i minnet. Därför är det enda taket för indexens storlek den maximala totala databasstorleken, som dokumenteras i den DTU-baserade inköpsmodellen och köpmodell baserad på virtuell kärna artiklar.

När du använder grupperade columnstore-index, används kolumnkomprimering för lagring av bastabeller. Den här komprimering kan avsevärt minska lagringsavtrycket för dina användardata, vilket innebär att du får plats med mer data i databasen. Komprimeringsförhållandet kan ökas ytterligare med kolumnarkivkomprimering. Mängden komprimering som du kan uppnå beror på typen av data, men 10 gånger komprimering är inte ovanligt.

Om du till exempel har en databas med en maximal storlek på 1 terabyte (TB) och du uppnår 10 gånger komprimering med hjälp av kolumnlagringsindex, får du plats med totalt 10 TB användardata i databasen.

När du använder icke-klustrade kolumnlagringsindex lagras bastabellen fortfarande i det traditionella radlagringsformatet. Därför är lagringsbesparingarna inte lika betydande som med grupperade kolumnlagringsindex. Men om du ersätter många traditionella icke-grupperade index med ett enda kolumnlagringsindex kan du fortfarande se en övergripande besparing i tabellens lagringsfotavtryck. Du kan också använda datakomprimering för bastabellen.

Ändra tjänstnivåer för databaser som innehåller kolumnlagringsindex

Om du använder DTU-inköpsmodellen och databasen innehåller kolumnlagringsindex kan programmet sluta fungera om du skalar databasen under S3-tjänstmålet. Kolumnlagringsindex stöds endast på tjänstnivåerna Hyperskala, Affärskritisk och Premium, samt på standardtjänstnivån om du använder S3 och senare. Kolumnlagringsindex stöds inte på den grundläggande tjänstnivån. När du skalar databasen till en tjänstnivå eller tjänstmål som inte stöds blir ditt kolumnlagringsindex otillgängligt. Systemet underhåller indexet när du kör DML-instruktioner, men det använder aldrig indexet. Om du senare skalar tillbaka till en tjänstnivå eller tjänstmål som stöds är ditt columnstore-index omedelbart redo att användas igen.

Om du har ett klustrat kolumnlagringsindex blir hela tabellen otillgänglig om databasen skalas till en tjänstnivå eller tjänstmål som inte stöds. Släpp alla klustrade kolumnlagringsindex och ersätt dem med klustrade radlagringsindex eller högar innan skalningsåtgärden.

Relaterat innehåll