Tjänstnivå för hyperskala

gäller för:Azure SQL Database

Azure SQL Database baseras på SQL Server Database Engine-arkitekturen som justeras för molnmiljön för att säkerställa hög tillgänglighet även i händelse av infrastrukturfel. Det finns tre alternativ på tjänstnivå i köpmodellen för virtuella kärnor för Azure SQL Database:

• Generell användning
• Affärskritisk
• Hyperskala

Tjänstnivån Hyperskala är lämplig för alla arbetsbelastningstyper. Dess molnbaserade arkitektur ger oberoende skalbar beräkning och lagring för att stödja den bredaste variationen av traditionella och moderna program. Beräknings- och lagringsresurser i Hyperskala överskrider avsevärt de resurser som är tillgängliga på nivåerna Generell användning och Affärskritisk.

Mer information om tjänstnivåerna Generell användning och Affärskritisk i den vCore-baserade inköpsmodellen finns i tjänstnivåer för generell användning och affärskritiska. En jämförelse av den VCore-baserade inköpsmodellen med den DTU-baserade inköpsmodellen finns i Compare vCore and DTU-based purchasing models of Azure SQL Database.

Tjänstnivån Hyperskala är för närvarande endast tillgänglig för Azure SQL Database och inte för Azure SQL Managed Instance.

Vilka är hyperskala-funktionerna?

Tjänstnivån Hyperskala i Azure SQL Database innehåller följande ytterligare funktioner:

• Snabb uppskalning – du kan i konstant tid skala upp dina beräkningsresurser för att hantera tunga arbetsbelastningar vid behov och sedan skala ned beräkningsresurserna igen när de inte behövs.
• Snabb utskalning – du kan etablera en eller flera endast läsbara repliker för att avlasta läsbelastningen och för användning som varm standby.
• Automatisk uppskalning, nedskalning och fakturering för beräkning baserad på användning med serverlös beräkning.
• Optimerat pris/prestanda för en grupp Hyperskala-databaser med varierande resurskrav med elastiska pooler.
• Automatisk skalning av lagring med stöd för upp till 128 TB databas eller elastisk poolstorlek på 100 TB.
• Högre övergripande prestanda på grund av högre dataflöde för transaktionsloggar och snabbare transaktionsincheckningstider oavsett datavolymer.
• Snabba säkerhetskopieringar av databaser (baserat på ögonblicksbilder av filer) oavsett storlek utan I/O-påverkan på beräkningsresurser.
• Snabb databasåterställning eller kopior (baserat på ögonblicksbilder av filer) på några minuter i stället för timmar eller dagar.

Tjänstnivån Hyperskala tar bort många av de praktiska gränser som traditionellt sett setts i molndatabaser. Om de flesta andra databaser begränsas av de resurser som är tillgängliga i en enda nod har databaser på tjänstnivån Hyperskala inga sådana gränser. Med sin flexibla lagringsarkitektur växer lagringen efter behov. Faktum är att Hyperskala-databaser inte skapas med en definierad maxstorlek. En Hyperskala-databas växer efter behov – och du debiteras endast för den allokerade lagringskapaciteten. För läsintensiva arbetsbelastningar ger tjänstnivån Hyperskala snabb utskalning genom att etablera ytterligare repliker efter behov för avlastning av läsarbetsbelastningar.

Dessutom är den tid som krävs för att skapa databassäkerhetskopior eller för att skala upp eller ned inte längre knuten till datavolymen i databasen. Hyperskala-databaser säkerhetskopieras nästan omedelbart. Du kan också skala en databas i tiotals terabyte upp eller ned inom några minuter på den etablerade beräkningsnivån eller använda serverlösa för att skala beräkning automatiskt. Den här funktionen befriar dig från bekymmer över att bli inrutad av dina ursprungliga konfigurationsval.

Mer information om beräkningsstorlekarna för tjänstnivån Hyperskala finns i Egenskaper för tjänstnivå.

Vem bör överväga Hyperskala-tjänstnivån?

Tjänstnivån Hyperskala är avsedd för alla kunder som behöver högre prestanda och tillgänglighet, snabb säkerhetskopiering och återställning samt/eller snabb skalbarhet för lagring och beräkning. Detta omfattar kunder som flyttar till molnet för att modernisera sina program och kunder som redan använder andra tjänstnivåer i Azure SQL Database. Tjänstnivån Hyperskala stöder ett brett utbud av databasarbetsbelastningar, från ren OLTP till ren analys. Den är optimerad för OLTP- och HTAP-arbetsbelastningar (hybridtransaktions- och analysbearbetning).

Prismodell för hyperskala

Obs

Förenklad prissättning för Azure SQL Database Hyperscale har kommit! Granska nya prisnivån för Azure SQL Database Hyperscale-meddelandeoch information om prisändringar finns i Azure SQL Database Hyperscale – lägre, förenklad prissättning!.

Tjänstnivån Hyperskala är tillgänglig endast i vCore-modell. För att anpassa till den nya arkitekturen skiljer sig prismodellen något från tjänstnivåerna Generell användning eller Affärskritisk:

• Etablerad beräkning:

  Priset för beräkningsenhet för hyperskala är per kopia. Användare kan justera det totala antalet sekundära repliker med hög tillgänglighet från 0 till 4, beroende på tillgänglighets- och skalbarhetskrav, och skapa upp till 30 namngivna repliker för att stödja olika utskalningsarbetsbelastningar.

• Serverlös beräkning:

  Serverlös beräkningsfakturering baseras på användning. Mer information finns i serverlös beräkningsnivå för Azure SQL Database.

• Förvaring:

  Du behöver inte ange den maximala datastorleken när du konfigurerar en Hyperskala-databas. På hyperskala-nivån debiteras du för lagring för databasen baserat på faktisk allokering. Lagring allokeras automatiskt mellan 10 GB och 128 TB och växer i steg om 10 GB efter behov.

För mer information om prissättning för Hyperscale, se Prissättning för Azure SQL Database.

Arkitektur för distribuerade funktioner

Hyperskala separerar frågebearbetningsmotorn från de komponenter som ger långsiktig lagring och hållbarhet för data. Med den här arkitekturen kan du smidigt skala lagringskapaciteten så långt det behövs (upp till 128 TB) och möjligheten att skala beräkningsresurser snabbt.

Följande diagram illustrerar den funktionella Hyperskala-arkitekturen:

Läs mer om Hyperscale-arkitekturen för distribuerade funktioner.

Skalnings- och prestandafördelar

Med möjligheten att snabbt skala upp/ner ytterligare läs-skrivskyddade beräkningsnoder, tillåter Hyperscale-arkitekturen betydande lässkalningsegenskaper och kan även frigöra den primära beräkningsnoden för att hantera fler skrivbegäranden. Dessutom kan beräkningsnoderna skalas upp/ned snabbt på grund av arkitekturen för delad lagring i Hyperskala-arkitekturen. Skrivskyddade beräkningsnoder i Hyperskala är också tillgängliga på den serverlösa beräkningsnivån, som automatiskt skalar beräkning baserat på efterfrågan på arbetsbelastningar.

Databas med hög tillgänglighet i Hyperskala

Precis som i alla andra tjänstnivåer garanterar Hyperscale datahållbarhet för utförda transaktioner oavsett tillgängligheten hos beräkningsrepliker. Omfattningen av stilleståndstid på grund av att den primära repliken blir otillgänglig beror på typen av redundans (planerad eller oplanerad), om zonredundans har konfigureratsoch om det finns minst en replik med hög tillgänglighet. I en planerad redundansväxling (till exempel en underhållshändelse) skapar systemet antingen den nya primära repliken innan en redundansväxling initieras eller använder en befintlig replik med hög tillgänglighet som redundansmål. I en oplanerad redundansväxling (till exempel ett maskinvarufel på den primära repliken) använder systemet en replik med hög tillgänglighet som ett redundansmål om det finns en sådan, eller skapar en ny primär replik från poolen med tillgänglig beräkningskapacitet. I det senare fallet är stilleståndstiden längre på grund av extra steg som krävs för att skapa den nya primära repliken.

Du kan välja ett underhållsfönster som gör att du kan göra påverkanskänsliga underhållshändelser förutsägbara och mindre störande för din arbetsbelastning.

Mer information om serviceavtal för Hyperskala finns i SLA för Azure SQL Database.

Buffertpool, elastiskt tillägg för buffertpooler och kontinuerlig priming

I Azure Database Hyperscale finns det en distinkt separation mellan beräkning och lagring. Lagringen innehåller alla databassidor i en databas och kan allokeras över flera datorer när databasen växer. Beräkningsnoden cachelagrar dock bara det som används nyligen. De hetaste sidorna i beräkning behålls i minnet i en struktur som kallas buffertpool (BP). Den lagras också i den lokala SSD:n, tillägget för elastisk buffertpool (RBPEX), så att data kan hämtas snabbare om beräkningsprocessen startas om.

I ett molnsystem kan beräkning flyttas till olika datorer efter behov. Beräkningslagret kan ha flera repliker. En är primär och tar emot alla uppdateringar, medan andra är sekundära repliker. I händelse av ett primärt fel kan en av de sekundära replikerna med hög tillgänglighet snabbt befordras till primär i en process som kallas redundans. Den sekundära repliken kanske inte har någon cache i sin BP och RBPEX som är optimerad för den primära arbetsbelastningen.

Kontinuerlig priming är en process som samlar in information om vilka sidor som är hetaste i alla beräkningsrepliker. Den informationen aggregeras och sekundära repliker med hög tillgänglighet använder listan över de hetaste sidorna som motsvarar den typiska kundarbetsbelastningen. Detta fyller både BP och RBPEX med de hetaste sidorna, kontinuerligt, för att hålla jämna steg med ändringar i kundens arbetsbelastning.

Utan kontinuerlig priming ärvs inte både BP och RBPEX av nya repliker med hög tillgänglighet och rekonstrueras endast under användararbetsbelastningen. Kontinuerlig priming sparar tid och förhindrar inkonsekventa prestanda, eftersom det inte finns någon väntan innan cacheminnena är helt hydratiserade igen. Med kontinuerlig initiering kommer nya sekundära repliker med hög tillgänglighet omedelbart att initiera sina BP och RBPEX. Detta bidrar till att upprätthålla prestandan mer konsekvent när redundansväxlingar sker.

Kontinuerlig priming fungerar på båda sätten: sekundära repliker med hög tillgänglighet cachelagrar sidor som används i den primära repliken och den primära cachelagrar sidor med arbetsbelastningen från de sekundära replikerna.

Obs

Kontinuerlig priming är för närvarande i en begränsad förhandsversion och är inte tillgänglig för serverlösa databaser. Mer information och om du vill välja kontinuerlig priming finns i Blogg: Förbättringar av Hyperskala i november 2024.

Säkerhetskopiera och återställa

Säkerhetskopierings- och återställningsåtgärder för Hyperskala-databaser är filögonblicksbaserade. Detta gör att dessa åtgärder kan vara nästan omedelbara. Eftersom Hyperskala-arkitekturen använder lagringslagret för säkerhetskopiering och återställning minskas bearbetningsbelastningen och prestandapåverkan för beräkningsrepliker. Läs mer i säkerhetskopieringar i hyperskala och lagringsredundans.

Haveriberedskap för Hyperskala-databaser

Om du behöver återställa en Hyperscale-databas i Azure SQL Database till en annan region än den där den för närvarande finns lokalt, som en del av en katastrofåterställning, övning, omlokalisering eller någon annan anledning, är den primära metoden att utföra en geo-återställning av databasen. Geo-återställning är endast tillgängligt när geo-redundant lagring (RA-GRS) har valts för lagringsredundans.

Läs mer i om att återställa en Hyperskala-databas till en annan region.

Jämför resursgränser

De vCore-baserade tjänstnivåerna är differentierade baserat på databastillgänglighet, lagringstyp, prestanda och maximal lagringsstorlek. Dessa skillnader beskrivs i följande tabell:

ㅤ	Allmän användning	Affärskritisk	Hyperskala
bäst för	Erbjuder budgetorienterade alternativ för balanserad beräkning och lagring.	OLTP-program med hög transaktionshastighet och låg I/O-svarstid. Erbjuder hög motståndskraft mot fel och snabba omkopplingar med hjälp av flera aktiva reservkopior.	Det bredaste utbudet av arbetsbelastningar. Lagringsstorlek för automatisk skalning upp till 128 TB, snabb lodrät och vågrät beräkningsskalning, snabb databasåterställning.
Beräkningsstorlek	2 till 128 virtuella kärnor	2 till 128 virtuella kärnor	2 till 128 virtuella kärnor
Lagringstyp	Premium-fjärrlagring (per instans)	Supersnabb lokal SSD-lagring (per instans)	Frikopplad lagring med lokal SSD-cache (per beräkningsreplik)
Lagringsstorlek	1 GB – 4 TB	1 GB – 4 TB	10 GB – 128 TB
IOPS	320 IOPS per virtuell kärna med maximalt 16 000 IOPS	4 000 IOPS per virtuell kärna med maximalt 327 680 IOPS	327 680 IOPS med maximal lokal SSD Hyperskala är en arkitektur med flera nivåer med cachelagring på flera nivåer. Effektiv IOPS beror på arbetsbelastningen.
minne/vCore	5,1 GB	5,1 GB	5,1 GB eller 10,2 GB
tillgänglighet	En replik, ingen utskalning, zonredundant HA	Tre repliker, en läsbar skalbar, zonredundant HA	Flera repliker, upp till fyra läsbara skalbara, zonredundanta HA
Säkerhetskopieringar	Ett val av lokalt redundant lagring (LRS), zonredundant (ZRS) eller geo-redundant lagring (GRS) Kvarhållning på 1–35 dagar (sju dagar som standard) med upp till 10 års långsiktig kvarhållning tillgänglig	Ett val av lokalt redundant lagring (LRS), zonredundant (ZRS) eller geo-redundant lagring (GRS) Kvarhållning på 1–35 dagar (sju dagar som standard) med upp till 10 års långsiktig kvarhållning tillgänglig	Ett val av lokalt redundant lagring (LRS), zonredundant (ZRS) eller geo-redundant lagring (GRS) Kvarhållning på 1–35 dagar (sju dagar som standard) med upp till 10 års långsiktig kvarhållning tillgänglig
Prissättning/fakturering	vCore, reserverad lagring och säkerhetskopieringslagring debiteras. IOPS debiteras inte.	vCore, reserverad lagring och säkerhetskopieringslagring debiteras. IOPS debiteras inte.	virtuella kärnor för varje replik, allokerad datalagring och lagring av säkerhetskopior debiteras. IOPS debiteras inte.
Rabattmodeller1	Reserverade instanser Azure-hybridförmån2 Enterprise- och Betala efter-You-Go Dev/Test-erbjudanden prenumerationer	Reserverade instanser Azure-hybridförmån2 Enterprise- och Betala efter-You-Go Dev/Test-erbjudanden prenumerationer	Reserverade instanser Azure-hybridförmån2 Enterprise- och Betala efter-You-Go Dev/Test-erbjudanden prenumerationer

¹ Förenklad prissättning för SQL Database Hyperscale kom i december 2023. Mer information finns i prisbloggen för Hyperskala.

² Från och med december 2023 är Azure Hybrid-förmånen inte tillgänglig för nya Hyperskala-databaser eller i dev/test-prenumerationer. Befintliga enkla Hyperskala-databaser med etablerad beräkning kan fortsätta att använda Azure Hybrid-förmånen för att spara på beräkningskostnader fram till december 2026. För mer information, se bloggen om prissättning för Hyperscale.

Beräkningsresurser

Maskinvarukonfiguration	CPU	Minne
Standardserie (Gen5)	Provisionerad datorkapacitet - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)1, Intel® 8272CL (Cascade Lake) 2,5 GHz1, Intel® Xeon® Platinum 8370C (Ice Lake)1, AMD EPYC 7763v (Milano) processorer – Etablera upp till 80 virtuella kärnor (hypertrådad) serverlös beräkning - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)1, Intel® 8272CL (Cascade Lake) 2,5 GHz1, Intel® Xeon® Platinum 8370C (Ice Lake)1, AMD EPYC 7763v (Milano) processorer – Skala upp till 80 virtuella kärnor automatiskt (hypertrådad) – Förhållandet mellan minne och virtuell kärna anpassas dynamiskt till minnes- och CPU-användning baserat på efterfrågan på arbetsbelastningar och kan vara så högt som 24 GB per virtuell kärna. Vid en viss tidpunkt kan till exempel en arbetsbelastning använda och debiteras för 240 GB minne och endast 10 virtuella kärnor.	Provisionerad datorkapacitet - 5,1 GB per vCore – Tilldela upp till 625 GB serverlös beräkning – Skala upp till 24 GB per virtuell kärna automatiskt – Skala upp till högst 240 GB automatiskt
Premium-serien	- Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC 7763v (Milano) processorer – Etablera upp till 128 virtuella kärnor (hypertrådad)	- 5,1 GB per vCore
Minnesoptimerad för Premium-serien	- Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC 7763v (Milano) processorer – Etablera upp till 80 virtuella kärnor (hypertrådad)	- 10,2 GB per vCore

¹ I vyn sys.dm_user_db_resource_governance dynamisk hantering maskinvarugenerering för databaser med Intel® SP-8160-processorer (Skylake) visas som Gen6, maskinvarugenerering för databaser med Intel® 8272CL (Cascade Lake) visas som Gen7 och maskinvarugenerering för databaser med Intel® Xeon® Platinum 8370C (Ice Lake) eller AMD® EPYC® 7763v (Milano) visas som Gen8. För en viss beräkningsstorlek och maskinvarukonfiguration är resursgränserna desamma oavsett cpu-typ. Mer information finns i resursgränser för enskilda databaser och elastiska pooler.

Serverlös stöds endast på Gen5-maskinvara (Standard-serien).

Skapa och hantera Hyperskala-databaser

Du kan skapa och hantera Hyperskala-databaser med hjälp av Azure-portalen, Transact-SQL, PowerShell och Azure CLI. Mer information finns i Snabbstart: Skapa en Hyperskala-databas.

Åtgärd	Detaljer	Läs mer
Skapa en hyperskala-databas	Hyperskala-databaser är endast tillgängliga med hjälp av den vCore-baserade inköpsmodellen.	Hitta exempel för att skapa en Hyperskala-databas i snabbstarten : Skapa en Hyperskala-databas i Azure SQL Database.
Uppgradera en befintlig databas till Hyperskala	Att migrera en befintlig databas i Azure SQL Database till Hyperskala-nivån är en operation av typen stor datamängd.	Lär dig hur du migrerar en befintlig databas till Hyperskala.
Omvänd migrering av en Hyperscale-databas till tjänstnivån Allmänt syfte	Om du tidigare migrerade en befintlig Azure SQL Database till Hyperskala kan du ångra migreringen av databasen till tjänstnivån Generell användning inom 45 dagar efter den ursprungliga migreringen till Hyperskala. Om du vill migrera databasen till en annan tjänstnivå, till exempel Business Critical, gör först en omvänd migration till tjänstnivån General Purpose, sedan ändrar du tjänstnivån.	Lär dig hur du omvänt migrerar från Hyperskala, inklusive begränsningar för omvänd migrering.

Begränsningar

Det här är de aktuella begränsningarna för tjänstnivån Hyperskala. Vi arbetar aktivt med att ta bort så många av dessa begränsningar som möjligt.

Utfärda	Beskrivning
Krympning blockeras när TDE är inaktiverat	För närvarande stöds inte databas- och filkrympningsåtgärder när transparent datakryptering (TDE) är inaktiverat i Azure SQL Database Hyperskala.
Återställa databasen från andra tjänstnivåer	En icke-Hyperskala-databas kan inte återställas som en Hyperskala-databas och en Hyperskala-databas kan inte återställas som en icke-Hyperskala-databas. För databaser som migreras till Hyperskala från andra Azure SQL Database-tjänstnivåer sparas säkerhetskopieringar före migreringen under hela kvarhållning av säkerhetskopior period av källdatabasen, inklusive långsiktiga kvarhållningsprinciper. Återställning av en säkerhetskopia före migreringen inom kvarhållningsperioden för säkerhetskopian av databasen stöds via kommandoraden. Du kan återställa dessa säkerhetskopior till valfri tjänstnivå som inte är hyperskala.
Migrering av databaser med In-Memory OLTP-objekt	Hyperskala stöder en delmängd av In-Memory OLTP-objekt, inklusive minnesoptimerade tabelltyper, tabellvariabler och inbyggda kompilerade moduler. Men när det finns In-Memory OLTP-objekt i databasen som migreras, stöds inte migrering från premium- och affärskritiska tjänstnivåer till Hyperskala. Om du vill migrera en sådan databas till Hyperskala måste alla In-Memory OLTP-objekt och deras beroenden tas bort. När databasen har migrerats kan dessa objekt återskapas. Varaktiga och icke-hållbara minnesoptimerade tabeller stöds för närvarande inte i Hyperskala och måste ändras till disktabeller.
Kontroll av databasintegritet	DBCC CHECKDB stöds inte för närvarande för Hyperskala-databaser. DBCC CHECKTABLE ('TableName') MED TABLOCK och DBCC CHECKFILEGROUP MED TABLOCK kan användas som ett tillvägagångssätt. Se Dataintegritet i Azure SQL Database för mer information om dataintegritetshantering i Azure SQL Database.
Elastiska jobb	Det går inte att använda en Hyperskala-databas som jobbdatabas. Elastiska jobb kan dock rikta in sig på Hyperskala-databaser på samma sätt som andra databaser i Azure SQL Database.
Datasynkronisering	Det går inte att använda en Hyperskala-databas som en hubb- eller synkroniseringsmetadatadatabas. En Hyperskala-databas kan dock vara en medlemsdatabas i en datasynkroniseringstopologi.
Hyperskale-tjänstnivåns Premium-seriens datorhårdvara	Premium-serien och minnesoptimerad premiumseriemaskinvara stöder för närvarande inte den serverlösa beräkningsnivån.
Regional tillgänglighet	Tillgång till Hyperscale-tjänstnivå med maskinvara i Premium-serien och minnesoptimerad Premium-serien finns i begränsade Azure-regioner. En lista finns i Tillgänglighet för Premium-serien i Hyperskala.

Relaterat innehåll

• Vanliga frågor och svar om Hyperskala
• Jämför virtuella kärnor och DTU-baserade köpmodeller för Azure SQL Database
• Resurshantering i Azure SQL Database
• Resursgränser för enskilda databaser med köpmodellen för virtuella kärnor
• jämförelse av funktioner: Azure SQL Database och Azure SQL Managed Instance
• arkitektur för distribuerade funktioner i hyperskala
• Hur man hanterar en hyperskala-databas