Tjänstnivå för hyperskala (storskalig)

gäller för:Azure SQL Database

Azure SQL Database Hyperskala är en kostnadseffektiv molndatabas med höga prestanda.

Azure SQL Database baseras på SQL-Database Engine. Hyperskala skiljer sig från andra Azure SQL Database tjänstnivåer:

  • Till skillnad från andra tjänstnivåer har Hyperscale ingen licensavgift för SQL-programvara, vilket ger den en betydande prisfördel jämfört med andra Azure SQL Database tjänstnivåer för högpresterande databaser.
  • Hyperskala-arkitekturen är distinkt: den ger nästan omedelbara säkerhetskopior, snabba återställningar och högt dataflöde för läsningar och skrivningar.
  • Hyperskala ger snabb beräkningsskalning på begäran utan dataflytt.
  • Det är enkelt att läsa utskalningsstrategier med upp till 30 namngivna repliker med oberoende konfigurerbar beräkning, plus inbyggda repliker med hög tillgänglighet och konfigurerbara geo-repliker över hela världen.

Tjänstnivån Hyperskala är lämplig för alla arbetsbelastningstyper. Beräknings- och lagringsresurser i Hyperskala överskrider avsevärt de resurser som är tillgängliga på nivåerna generell användning och affärskritiska Azure SQL Database.

Du kan enkelt konvertera en befintlig databas i Azure SQL Database till Hyperskala eller migrera från valfri SQL Server databas till Hyperskala. Information om hur du migrerar andra databaser till Azure SQL Database finns i Azure Databasmigreringsguider.

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 – skala upp dina beräkningsresurser för att hantera tunga arbetsbelastningar när det behövs och skala sedan ned beräkningsresurserna igen när de inte behövs.
  • Snabb utskalning – etablera en eller flera skrivskyddade repliker för avlastning av läsarbetsbelastningen och för användning som frekventa väntelägen.
  • 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 erbjuder tjänstnivån Hyperskala snabb utskalning genom att tillhandahålla ytterligare repliker vid behov. Detta sker för att avlasta 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å.

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- och DTU-baserade inköpsmodeller för Azure SQL Database.

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 snabb lagrings- och beräkningsskalbarhet. Hyperskala är perfekt för kunder som flyttar till molnet för att modernisera sina program eller för 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

För databaser med höga prestanda erbjuder Hyperskala en betydande prisfördel jämfört med andra Azure SQL Database tjänstnivåer. Mer information finns i Blogg: prisinformation för Azure SQL Database Hyperscale från Ignite 2023. Information om prisändringar finns i Blogg: Azure SQL Database Hyperskala – lägre, förenklad prissättning!

Tjänstnivån Hyperskala är endast tillgänglig i modellen med virtuella kärnor och finns på två beräkningsnivåer. Faktureringen för Hyperskala baseras på den etablerade eller serverlösa beräkningsnivån:

Du anger inte den maximala datastorleken när du konfigurerar en Hyperskala-databas. På Hyperskala-nivån betalar du för lagring baserat på faktisk allokering. Lagringen allokeras automatiskt mellan 10 GB och 128 TB och växer efter behov. För mer information, se I vilka steg växer min databasstorlek?

Skalnings- och prestandafördelar

Hyperskala separerar huvuddatabasmotorn från de komponenter som ger långsiktig lagring och hållbarhet för data. Med den här arkitekturen kan du skala beräkningsresurser snabbt, utan dataflytt och skala lagring (upp till 128 TB) oberoende av beräkning. Mer information, inklusive ett arkitekturdiagram, finns i Hyperskala-arkitektur.

  • Med möjligheten att snabbt skala upp och ned ytterligare skrivskyddade beräkningsnoder ger Hyperscale-arkitekturen avsevärt ökad läskapacitet och kan även frigöra den primära beräkningsnoden så att den kan betjäna fler förfrågningar.
  • Du kan provisionera beräkningen för sekundära noder eller använda serverless beräkning. I båda fallen kan du skala upp eller ned dem snabbt på grund av arkitekturen för delad lagring i Hyperskala.
    • Sekundära repliker av beräkningsnoder med hög tillgänglighet i Hyperscale följer den primära nodens beräkningsskikt, vilket resulterar i redundansväxlingar med låg påverkan.
  • När du använder serverlösa, primära eller sekundära beräkningsnoder skalas automatiskt baserat på din arbetsbelastningsefterfrågan.

Den primära Azure SQL Database Hyperskala-databasen hanterar både läs- och skrivarbetsbelastningar, men du kan enkelt skapa skrivskyddade repliker som en del av din programstrategi:

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 för att göra underhållshändelser med stor påverkan förutsägbara och mindre störande för dina arbetsbelastningar.

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

Buffertpool och tillägg för feltolerant buffertpool

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 replik är primär och tar emot alla uppdateringar, medan de andra är sekundära repliker. Om det primära misslyckas befordrar systemet en av de sekundära replikerna med hög tillgänglighet till primära 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

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

Utan kontinuerlig primning övertas varken BP eller 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 bibehålla en mer konsekvent prestanda när felövergångar 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 repliken cachelagrar sidor med belastningen från de sekundära replikerna.

Kontinuerlig priming är för närvarande tillgängligt på den etablerade beräkningsnivån Hyperskala.

Säkerhetskopiera och återställa

Säkerhetskopierings- och återställningsåtgärder för Hyperskala-databaser är filögonblicksbaserade. Den här metoden gör dessa åtgärder nästan omedelbara. Eftersom Hyperskala-arkitekturen använder lagringslagret för säkerhetskopiering och återställning minskar bearbetningsbelastningen och prestandapåverkan på beräkningsrepliker. Mer information finns i Hyperskala-säkerhetskopior och lagringsredundans.

Haveriberedskap för Hyperskala-databaser

Om du vill återställa en Hyperskala-databas i Azure SQL Database till en annan region än den som den för närvarande finns i utför du en geo-återställning. Den här metoden kan användas för katastrofåterställningsåtgärder, övningar, omlokalisering eller av någon annan anledning. Geo-återställning är endast tillgängligt när du väljer geo-redundant lagring (RA-GRS) för lagringsredundans.

Mer information finns i återställa en Hyperskala-databas till en annan region.

Jämför resursgränser

De vCore-baserade tjänstnivåerna skiljer sig åt i databastillgänglighet, lagringstyp, prestanda och maximal lagringsstorlek. I följande tabell beskrivs dessa skillnader:

ㅤ Generell användning Affärskritisk Hyperskala
Bäst för Budgetorienterade alternativ för balanserad beräkning och lagring. OLTP-program med hög transaktionshastighet och låg I/O-svarstid. Hög motståndskraft mot fel och snabba redundansväxlingar med hjälp av flera repliker med frekvent vänteläge. Den rekommenderade tjänstnivån och standardnivån för alla nya och moderniserande OLTP- och HTAP-arbetsbelastningar. Bäst för bredast möjliga arbetsbelastningar, inklusive de arbetsbelastningar med mycket skalbar lagring och lässkalningskrav. Ger högre motståndskraft mot fel genom att tillåta konfiguration av mer än en sekundär replik med hög tillgänglighet.
Beräkningsstorlek 2 till 128 virtuella kärnor 2 till 128 virtuella kärnor 2 till 192 virtuella kärnor3
Lagringstyp Premium-fjärrlagring (per instans) Supersnabb lokal SSD-lagring (per instans) Frikopplad lagring med lokal SSD-cache (per beräkningsenhet)
Lagringsstorlek 1 GB – 4 TB 1 GB – 4 TB 10 GB – 128 TB
Maximalt antal IOPS 320 IOPS per virtuell kärna med maximalt 16 000 IOPS 4 000 IOPS per virtuell kärna med maximalt 327 680 IOPS 5 500 IOPS per virtuell kärna med högst 544 000 lokala SSD IOPS.
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
Backups Ett val av lokalt redundant lagring (LRS), zonredundant (ZRS) eller geo-redundant lagring (GRS)
1–35 dagars kvarhållning (7 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)
1–35 dagars kvarhållning (7 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)
1–35 dagars kvarhållning (7 dagar som standard), med upp till 10 års långsiktig kvarhållning tillgänglig
Tillgänglighet En replik, inga utskalningsrepliker. Zonsredundant HA Tre repliker, en läsbar utskalningsreplik. Zonsredundant HA Flera repliker, upp till 4 utskalningsrepliker. Zonsredundant HA
Prissättning/fakturering vCore, reserverad lagring och lagring av säkerhetskopior debiteras.
IOPS debiteras inte.		 vCore, reserverad lagring och lagring av säkerhetskopior debiteras.
IOPS debiteras inte.		 virtuella kärnor för varje replik, allokerad datalagring och lagring av säkerhetskopior debiteras.
IOPS debiteras inte.
Rabattmodeller1 Azure Reservation
Azure-hybridförmån2
Enterprise- och Betala per användningYou-Go Dev/Test-erbjudande prenumerationer		 Azure Reservation
Azure-hybridförmån2
Enterprise- och Betala per användningYou-Go Dev/Test-erbjudande prenumerationer		 Eftersom Hyperscale inte har någon licensavgift för SQL-programvara1 är Azure Hybrid Benefit inte tillgängligt för nya Hyperskala-databaser2.
Minnesinterna tabeller Nej. Yes Nej

1 Förenklad prissättning för SQL Database Hyperscale kom i december 2023. Se Hyperscale-prisbloggen för detaljer.

2 Från och med december 2023 är Azure Hybrid Benefit inte tillgängligt 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 Benefit för att spara på beräkningskostnader fram till december 2026. För mer information, se bloggen om prissättning för Hyperscale.

3 För närvarande är alternativen 160 och 192 virtuella kärnor en förhandsgranskningsfunktion.

Beräkningsresurser

I följande tabell jämförs beräkningsresurser i olika maskinvarukonfigurationer och beräkningsnivåer för Azure SQL Database Hyperscale. Mer information om Azure SQL Database som inte är hyperskala finns i köpmodellen för virtuella kärnor – Azure SQL Database.

Maskinvarukonfiguration CPU (centralenhet) Minne
Standardserie (Gen5) Provisionerad datorkapacitet
- Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)*, Intel® 8272CL (Cascade Lake) 2,5 GHz*, Intel® Xeon® Platinum 8370C (Ice Lake)*, AMD EPYC™ 7763v (Milano)*, AMD EPYC 9004 (Genoa)*, Intel® Xeon® Platinum 8573C (Emerald Rapids)* processorer
– Provisionera upp till 128 virtuella kärnor (med hypertrådning)

Serverlös databearbetning
- Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)*, Intel® 8272CL (Cascade Lake) 2,5 GHz*, Intel® Xeon® Platinum 8370C (Ice Lake)*, AMD EPYC™ 7763v (Milano)*, AMD EPYC 9004 (Genoa)*, Intel® Xeon® Platinum 8573C (Emerald Rapids)* 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 faktureras 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 databearbetning
– Skala upp till 24 GB per virtuell kärna automatiskt
– Skala upp till högst 240 GB automatiskt
Premium-serien Provisionerad datorkapacitet
- Intel® Xeon® Platinum 8370C (Ice Lake)*, AMD EPYC™ 7763v (Milano)*, AMD EPYC 9004 (Genua)*, Intel® Xeon® Platinum 8573C (Emerald Rapids)* processorer
– Etablera upp till 192 virtuella kärnor (hypertrådad).		 5,2 GB per vCore
Minneoptimerad Premium-serie Provisionerad datorkapacitet
- Intel® Xeon® Platinum 8370C (Ice Lake)*, AMD EPYC™ 7763v (Milano)*, AMD EPYC 9004 (Genua)*, Intel® Xeon® Platinum 8573C (Emerald Rapids)* processorer
– Tillhandahålla upp till 80 vCores (hypertrådade).		 10,2 GB per virtuell kärna

* För en viss beräkningsstorlek och maskinvarukonfiguration är resursgränserna desamma oavsett CPU-typ (Intel® Broadwell, Skylake, Ice Lake, Cascade Lake, Emerald Rapid eller AMD Milan, Genua). I vyn sys.dm_user_db_resource_governance dynamisk hantering skapar du maskinvara för databaser med hjälp av:

  • Intel® SP-8160-processorer (Skylake) visas som Gen6
  • Intel® 8272CL (Cascade Lake) visas som Gen7
  • Intel® Xeon® Platinum 8370C (Ice Lake) eller AMD EPYC™ 7763v (Milano) visas som Gen8
  • AMD EPYC™ 9004 (Genua) visas som Gen9 eller Intel® Xeon® Platinum 8573C (Emerald Rapids) visas som Gen10

Mer information finns i resursgränser för enskilda databaser och elastiska pooler.

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.

Operation Detaljer Läs mer
Skapa en hyperskala-databas Hyperskala-databaser är endast tillgängliga med hjälp av den vCore-baserade köpmodellen. Hitta exempel för att skapa en Hyperskala-databas i Quickstart: Skapa en Hyperskala-databas i Azure SQL Database.
Konvertera en befintlig databas till Hyperskala Du kan konvertera en befintlig databas till nivån Azure SQL Database Hyperskala. Konverteringstiden beror på datastorleken. Mer information finns i Konvertera en befintlig databas till Hyperskala.
Omvänd migrering av en Hyperscale-databas till tjänstnivån Allmänt syfte Om du tidigare har migrerat 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 Affärskritisk, återställer du först migreringen till tjänstnivån Generell användning och ändrar sedan tjänstnivån.		 Lär dig hur du omvänt migrerar från Hyperskala, inklusive begränsningar för omvänd migrering.

Begränsningar

Dessa begränsningar gäller för närvarande för tjänstnivån Hyperskala. Produktteamet 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öder Azure SQL Database Hyperskala inte databas- och filkrympningsåtgärder när Transparent Data Encryption (TDE) är inaktiverat.
Återställa databasen från andra tjänstnivåer Du kan inte återställa en icke-Hyperskala-databas som en Hyperskala-databas. Du kan inte heller återställa en Hyperskala-databas 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 kvarhållningsperioden för säkerhetskopior för källdatabasen, inklusive långsiktiga kvarhållningsprinciper. Du kan återställa en säkerhetskopia före migreringen inom kvarhållningsperioden för säkerhetskopian av databasen 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 du släppa alla In-Memory OLTP-objekt och deras beroenden. När databasen har migrerats kan du återskapa dessa objekt. 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 och DBCC CHECKFILEGROUP stöds för närvarande inte för Azure SQL Database Hyperscale-databaser. Som en lösning, använd DBCC CHECKTABLE ('TableName') WITH TABLOCK. Mer information om hantering av dataintegritet i Azure SQL Database finns i Dataintegritet 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.
Datasynk 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 Data Sync topologi.
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. Serverlös stöds endast på Gen5-maskinvara (Standard-serien).
Regional tillgänglighet Tjänstenivån Hyperscale och maskinvara i Premium-serien samt minnesoptimerad Premium-serien-maskinvara är tillgänglig i begränsade Azure-regioner. En lista finns i Tillgänglighet för Premium-serien i Hyperskala.

Relaterat innehåll

  • Last updated on