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

Artikel
2025-03-05

gäller för:Azure SQL Managed Instance

Med minnesintern teknik kan du förbättra programmets prestanda och potentiellt minska kostnaden för din SQL-hanterade instans. Minnesintern OLTP är tillgängligt på tjänstnivån Affärskritisk i Azure SQL Managed Instance.

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 ett mindre antal data, till exempel CRUD-åtgärder (create/read/update/delete).
Analytisk (onlineanalysbearbetning (OLAP)) där de flesta frågorna har komplexa beräkningar för rapporteringssyfte och även regelbundet schemalagda processer som utför belastningsoperationer (eller massinläsning) 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 Managed Instance stöder följande minnesintern teknik:

minnesintern OLTP- ökar antalet transaktioner per sekund och minskar svarstiden för transaktionsbearbetning. Scenarier som drar nytta av minnesintern 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.
Grupperade kolumnlagringsindex minskar er lagringsavtryck (upp till 10 gånger) och förbättrar prestanda för rapport- 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 om ditt företag genom att fråga den operativa databasen direkt, utan att behöva köra en dyr ETL-process (extrahering, transformering och inläsning) och vänta på att datalagret fylls på. Icke-klustrade kolumnstore-index tillåter snabb körning av analytiska frågor på OLTP-databasen, samtidigt som påverkan på den operativa arbetsbelastningen minskar.
minnesoptimerade grupperade kolumnlagringsindex för HTAP möjliggör snabb transaktionsbearbetning och att du samtidigt kan köra analyssökningar mycket snabbt på samma data.

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

Notera

En detaljerad handledning steg-för-steg för att demonstrera prestandafördelarna med minnesintern OLTP-teknik, med hjälp av AdventureWorksLT exempeldatabas och ostress.exe, finns i exempel på minnesintern i Azure SQL Managed Instance.

Fördelar med minnesintern teknik

Tack vare den effektivare fråge- och transaktionsbearbetningen hjälper minnesintern teknik dig också att minska kostnaderna. Väl på tjänstnivån Affärskritisk i Azure SQL Managed Instance behöver du vanligtvis inte uppgradera den SQL-hanterade instansen 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.

Den här artikeln beskriver aspekter av minnesinterna OLTP- och columnstore-index som är specifika för Azure SQL Managed Instance och innehåller även exempel:

Du ser hur dessa tekniker påverkar lagrings- och datastorleksgränserna.
Du ser hur du hanterar förflyttningen av databaser som använder dessa tekniker mellan de olika prisnivåerna.
Du ser två exempel som illustrerar användningen av minnesintern OLTP samt kolumnlagringsindex.

Mer information om minnesintern OLTP i SQL Server finns i:

Minnesintern OLTP-översikt och användningsscenarier (innehåller referenser till kundfallsstudier och information för att komma igång)
Dokumentation för minnesintern OLTP
Guide för kolumnstoreindex
Hybridtransaktions-/analysbearbetning (HTAP), även kallat driftanalys i realtid

Minnesintern OLTP

Minnesintern 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 minnesinterna OLTP-data:

Memory-optimized radlager format där varje rad är ett separat minnesobjekt. Detta är ett klassiskt minnesinternt 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:
- Beständiga tabeller (SCHEMA_AND_DATA) där rader placerade 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.

Obs

Minnesintern 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 SQL-hanterad instans som har tillräckligt med minne. Mer information finns i Datastorlek och lagringsgräns för minnesintern OLTP-.

En snabb primer på minnesintern OLTP: Snabbstart 1: Minnesintern OLTP-teknik för snabbare T-SQL-prestanda.

Datastorlek och lagringsgräns för minnesintern OLTP

Minnesintern 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. Den här idén kallas minnesintern OLTP-lagring.

Tjänstnivån Affärskritisk innehåller en viss mängd Max In-Memory OLTP-minne, bestäms av antalet virtuella kärnor.

Följande objekt räknas mot det minnesinterna OLTP-lagringstaket:

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 kvotgränsen får du ett kvotöverskridandefel 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 prisnivån för databasen eller poolen.

Mer information om övervakning av minnesintern OLTP-lagringsanvändning och konfiguration av aviseringar när du nästan når taket finns i Övervaka minnesintern lagring.

Ändra maskinvarukonfiguration eller antal virtuella kärnor

Om du nedgraderar maskinvarukonfigurationen eller antalet virtuella kärnor kan det påverka din SQL-hanterade instans negativt.

Data i minnesoptimerade tabeller måste passa inom minnesintern OLTP-lagringsgräns för din maskinvarukonfiguration och antalet virtuella kärnor. Om du försöker skala ned till en inställning som inte har tillräckligt med tillgänglig OLTP-lagring i minnet misslyckas åtgärden.

Avgöra om minnesinterna objekt finns

Det finns ett programmatiskt sätt att förstå om en viss databas i din SQL-hanterade instans stöder minnesintern OLTP. Du kan köra följande Transact-SQL fråga:

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

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

Följande frågor identifierar alla objekt med minnesintern teknik:

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 kolumndatalager

Med den minnesinterna kolumnlagertekniken kan du lagra och fråga 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å förbättringar med upp till 10 gånger bättre datakomprimering jämfört med den okomprimerade datastorleken.

Det finns två typer av columnstore-modeller 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 modellen placeras alla rader i tabellen i kolumnformat som mycket komprimerar data 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. Grupperad kolumnlagringsmodell 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 modellen är ett bra val för scenarier med klassiska informationslager.
Icke-klustrad kolumnlagring där data lagras i en traditionell radlagringstabell och det finns ett index i kolumnlagringsformatet som används för analysfrågorna. Den här modellen möjliggör Hybrid Transactional-Analytic Processing (HTAP): möjligheten att köra högpresterande 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å ytterligare kolumnlagringsindex bör dock vara i storleksordningen mindre än motsvarande B-trädindex.

OBS

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 minnesinterna kolumnlagringsstrukturer överskrida mängden tillgängligt minne.

Datastorlek och lagring för kolumnlagringsindex

Det krävs inte att kolumnlagringsindex får plats i minnet. Därför är det enda taket för indexens storlek den maximala totala databasstorleken. Mer information finns i resursbegränsningar för Azure SQL Managed Instance. Azure SQL Managed Instance stöder columnstore-index på alla nivåer.

När du använder grupperade kolumnlagringsindex används kolumnkomprimering för lagring av bastabellen. 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. Komprimeringen kan ytterligare ökas 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.

Dela via