Hyperscale-servicelaag

van toepassing op:Azure SQL Database-

Azure SQL Database is gebaseerd op de architectuur van SQL Server Database Engine die is aangepast voor de cloudomgeving om ervoor te zorgen dat een hoge beschikbaarheid zelfs in gevallen van infrastructuurfouten. Er zijn drie opties voor de servicelaag in het vCore-aankoopmodel voor Azure SQL Database:

• Algemeen gebruik
• Bedrijfskritisch
• Hyperscale

De Hyperscale-servicelaag is geschikt voor alle workloadtypen. De cloudeigen architectuur biedt onafhankelijk schaalbare compute en opslag ter ondersteuning van de breedste verscheidenheid aan traditionele en moderne toepassingen. Reken- en opslagresources in Hyperscale overschrijden aanzienlijk de resources die beschikbaar zijn in de lagen Algemeen gebruik en Bedrijfskritiek.

Zie voor meer informatie over de servicelagen Algemeen gebruik en Bedrijfskritiek in het aankoopmodel op basis van vCore Algemeen gebruik en Bedrijfskritieke servicelagen. Voor een vergelijking van het aankoopmodel op basis van vCore met het aankoopmodel op basis van DTU, raadpleegt u Aankoopmodellen van vCore en DTU vergelijken met azure SQL Database-.

De Hyperscale-servicelaag is momenteel alleen beschikbaar voor Azure SQL Database en niet voor Azure SQL Managed Instance.

Wat zijn de Hyperscale-mogelijkheden?

De Hyperscale-servicelaag in Azure SQL Database biedt de volgende aanvullende mogelijkheden:

• Snel omhoog schalen: u kunt, in constante tijd, uw rekenresources omhoog schalen om zo nodig zware werkbelastingen te verwerken en vervolgens de rekenresources weer omlaag te schalen wanneer dat niet nodig is.
• Snelle schaalvergroting: u kunt een of meer alleen-lezen replica's inrichten voor het ontlasten van uw leesbelasting en voor gebruik als hot stand-bys.
• Automatisch opschalen, afschalen en facturering voor rekenkracht op basis van gebruik met serverloze compute.
• Geoptimaliseerde prijs/prestaties voor een groep Hyperscale-databases met verschillende resourcevereisten met elastische pools.
• Automatisch schalen van opslag met ondersteuning voor maximaal 128 TB aan database- of 100 TB elastische poolgrootte.
• Hogere algehele prestaties vanwege een hogere doorvoer van transactielogboeken en snellere doorvoer van transacties, ongeacht gegevensvolumes.
• Snelle databaseback-ups (op basis van momentopnamen van bestanden) ongeacht de grootte zonder I/O-invloed op rekenresources.
• Snelle database herstelt of kopieert (op basis van momentopnamen van bestanden) in minuten in plaats van uren of dagen.

De Hyperscale-servicelaag verwijdert veel van de praktische limieten die traditioneel worden gezien in clouddatabases. Wanneer de meeste andere databases worden beperkt door de resources die beschikbaar zijn in één knooppunt, hebben databases in de Hyperscale-servicelaag dergelijke limieten niet. Met de flexibele opslagarchitectuur groeit de opslag naar behoefte. Hyperscale-databases worden zelfs niet gemaakt met een gedefinieerde maximale grootte. Een Hyperscale-database groeit naar behoefte en u wordt alleen gefactureerd voor de toegewezen opslagcapaciteit. Voor leesintensieve workloads biedt de Hyperscale-servicelaag snelle uitschaling door extra replica's in te richten indien nodig voor het offloaden van leesworkloads.

Daarnaast is de tijd die nodig is om databaseback-ups te maken of omhoog of omlaag te schalen niet meer gekoppeld aan het volume aan gegevens in de database. Er wordt vrijwel onmiddellijk een back-up gemaakt van Hyperscale-databases. U kunt een database in de tientallen terabytes ook binnen enkele minuten omhoog of omlaag schalen in de ingerichte rekenlaag of serverloze gebruiken om de berekening automatisch te schalen. Deze mogelijkheid bevrijdt u van zorgen over te beperkte beslissingen door uw initiële configuratiekeuzes.

Zie voor meer informatie over de rekengrootten voor de Hyperscale-servicelaag kenmerken van de servicelaag.

Wie moet de Hyperscale-servicelaag overwegen

De Hyperscale-servicelaag is bedoeld voor alle klanten die hogere prestaties en beschikbaarheid nodig hebben, snelle back-up en herstel, en/of snelle opslag- en rekenschaalbaarheid. Dit omvat klanten die overstappen naar de cloud om hun toepassingen te moderniseren en klanten die al andere servicelagen gebruiken in Azure SQL Database. De Hyperscale-servicelaag ondersteunt een breed scala aan databaseworkloads, van pure OLTP tot pure analyse. Het is geoptimaliseerd voor OLTP- en HTAP-workloads (Hybrid Transaction and Analytical Processing).

Prijsmodel voor Hyperscale

Notitie

Er zijn vereenvoudigde prijzen voor Azure SQL Database Hyperscale aangekomen. Bekijk de nieuwe prijscategorie voor de Azure SQL Database Hyperscale-aankondiging, en voor details over de prijswijziging, zie Azure SQL Database Hyperscale – lagere, vereenvoudigde prijzen!.

De Hyperscale-servicelaag is alleen beschikbaar in vCore-model. Als u zich wilt aansluiten bij de nieuwe architectuur, verschilt het prijsmodel enigszins van de servicelagen Algemeen gebruik of Bedrijfskritiek:

• geprovisioneerde rekencapaciteit:

  De prijs van de Hyperscale-rekeneenheid is voor elke replica. Gebruikers kunnen het totale aantal secundaire replica's met hoge beschikbaarheid aanpassen van 0 tot 4, afhankelijk van de beschikbaarheids- en schaalbaarheidsvereisten, en maximaal 30 benoemde replica's maken ter ondersteuning van verschillende uitschaalworkloads voor lezen.

• serverloze berekening:

  Facturering voor serverloze rekenkracht is gebaseerd op gebruik. Zie Serverloze rekenlaag voor Azure SQL Databasevoor meer informatie.

• Storage:

  U hoeft niet de maximale gegevensgrootte op te geven bij het configureren van een Hyperscale-database. In de Hyperscale-laag worden kosten in rekening gebracht voor opslag voor uw database op basis van de werkelijke toewijzing. Opslag wordt automatisch toegewezen tussen 10 GB en 128 TB en groeit indien nodig in stappen van 10 GB.

Zie Prijzen van Azure SQL Databasevoor meer informatie over prijzen van Hyperscale.

Architectuur voor gedistribueerde functies

Hyperscale scheidt de queryverwerkingsengine van de onderdelen die langetermijnopslag en duurzaamheid bieden voor de gegevens. Met deze architectuur kunt u de opslagcapaciteit zo veel mogelijk schalen (tot 128 TB) en de mogelijkheid om rekenresources snel te schalen.

In het volgende diagram ziet u de functionele Hyperscale-architectuur:

Meer informatie over de architectuur van gedistribueerde Hyperscale-functies.

Voordelen van schaal en prestaties

Met de mogelijkheid om snel extra read-only rekenknooppunten op te zetten, biedt de Hyperscale-architectuur aanzienlijke mogelijkheden voor het opschalen van lezen en kan het primaire rekenknooppunt vrijmaken voor het verwerken van meer schrijfverzoeken. Bovendien kunnen de rekenknooppunten snel omhoog/omlaag worden geschaald vanwege de architectuur voor gedeelde opslag van de Hyperscale-architectuur. Alleen-lezen rekenknooppunten in Hyperscale zijn ook beschikbaar in de serverloze computelaag, waarmee computekracht automatisch wordt geschaald op basis van de werklast.

Hoge beschikbaarheid van databases in Hyperscale

Net als in alle andere servicelagen garandeert Hyperscale de duurzaamheid van gegevens voor doorgevoerde transacties, ongeacht de beschikbaarheid van replika's. De mate van downtime omdat de primaire replica niet beschikbaar is, is afhankelijk van het type failover (gepland versus ongepland), of zoneredundantie is geconfigureerden op de aanwezigheid van ten minste één replica met hoge beschikbaarheid. In een geplande failover (zoals een onderhoudsgebeurtenis) maakt het systeem de nieuwe primaire replica voordat een failover wordt gestart of gebruikt een bestaande replica met hoge beschikbaarheid als failoverdoel. In een niet-geplande failover (zoals een hardwarefout op de primaire replica), gebruikt het systeem een replica met hoge beschikbaarheid als failoverdoel als er een bestaat of maakt een nieuwe primaire replica uit de pool met beschikbare rekencapaciteit. In het laatste geval duurt de downtime langer vanwege extra stappen die nodig zijn om de nieuwe primaire replica te maken.

U kunt een onderhoudsvenster kiezen waarmee u impactvolle onderhoudsevenementen voorspelbaar en minder verstorend kunt maken voor uw workload.

Raadpleeg voor Hyperscale SLA SLA voor Azure SQL Database.

Bufferpool, veerkrachtige bufferpoolextensie en continue voorbewerking

In Azure Database Hyperscale is er een afzonderlijke scheiding tussen rekenkracht en opslag. Opslag bevat alle databasepagina's in één database en kan worden toegewezen over meerdere computers naarmate de database groeit. Het rekenknooppunt slaat echter alleen in de cache op wat er onlangs wordt gebruikt. De heetste pagina's in computer worden in het geheugen onderhouden in een structuur met de naam bufferpool (BP). Het wordt ook opgeslagen in de lokale SSD, de tolerante buffergroepextensie (RBPEX), zodat gegevens sneller kunnen worden opgehaald als het rekenproces opnieuw wordt opgestart.

In een cloudsysteem kan compute naar verschillende computers worden verplaatst, indien nodig. De rekenlaag kan meerdere replica's hebben. Een is primair en ontvangt alle updates, terwijl andere secundaire replica's zijn. In het geval van een primaire fout kan een van de secundaire replica's met hoge beschikbaarheid snel worden gepromoveerd naar primair in een proces dat failover wordt genoemd. De secundaire replica heeft mogelijk geen cache in de BP en RBPEX die zijn geoptimaliseerd voor de primaire workload.

Doorlopende priming is een proces dat informatie verzamelt over welke pagina's het heetst zijn in alle rekenreplica's. Deze informatie wordt geaggregeerd en secundaire replica's met hoge beschikbaarheid maken gebruik van de lijst met populairste pagina's die overeenkomen met de typische werkbelasting van de klant. Hiermee worden continu zowel de BP als de RBPEX gevuld met de meest gebruikte pagina's om veranderingen in de werklast van de klant bij te houden.

Zonder doorlopende priming worden BP en RBPEX niet overgenomen door nieuwe replica's met hoge beschikbaarheid en kunnen ze alleen gereconstrueerd worden tijdens de workload van de gebruiker. Continue priming bespaart tijd en voorkomt inconsistente prestaties, omdat er geen wachttijd is voordat de caches volledig gehydrateerd zijn. Met continue priming beginnen nieuwe secundaire replica's met hoge beschikbaarheid onmiddellijk met het aanbrengen van hun BP en RBPEX. Dit helpt de prestaties consistenter te houden naarmate er failovers plaatsvinden.

Continue priming werkt in beide richtingen: secundaire replica's met hoge beschikbaarheid cachen pagina's die worden gebruikt in de primaire replica, en de primaire replica cacht pagina's met de werklast van de secundaire replica's.

Notitie

Doorlopende priming bevindt zich momenteel in een beperkte preview en is niet beschikbaar voor serverloze databases. Voor meer informatie en om u aan te melden voor continue priming, zie Blog: verbeteringen van november 2024 Hyperscale.

Back-up maken en herstellen

Back-up- en herstelbewerkingen voor Hyperscale-databases zijn gebaseerd op bestandsmomentopnamen. Hierdoor kunnen deze bewerkingen bijna onmiddellijk worden uitgevoerd. Omdat de Hyperscale-architectuur gebruikmaakt van de opslaglaag voor back-up en herstel, worden de verwerkingsbelasting en prestatie-impact op rekenreplica's verminderd. Meer informatie vindt u in Hyperscale-back-ups en opslagredundantie.

Herstel na noodgevallen voor Hyperscale-databases

Als u een Hyperscale-database in Azure SQL Database wilt herstellen naar een andere regio dan de regio waarin deze momenteel wordt gehost, als onderdeel van een noodherstelbewerking, oefening, verhuizing of om een andere reden, is de primaire methode om een geo-herstel van de database te herstellen. Geo-herstel is alleen beschikbaar wanneer geografisch redundante opslag (RA-GRS) is gekozen voor opslagredundantie.

Meer informatie in het herstellen van een Hyperscale-database naar een andere regio.

Resourcelimieten vergelijken

De servicelagen op basis van vCore zijn gedifferentieerd op basis van databasebeschikbaarheid, opslagtype, prestaties en maximale opslaggrootte. Deze verschillen worden beschreven in de volgende tabel:

ㅤ	algemeen gebruik	Bedrijfskritieke	Hyperscale
Het beste voor	Biedt budgetgerichte, evenwichtige opties voor rekenen en opslag.	OLTP-toepassingen met een hoge transactiesnelheid en lage I/O-latentie. Biedt een hoge tolerantie voor storingen en snelle failovers met behulp van meerdere hot standby-replica's.	De meest uiteenlopende workloads. Automatisch schalen van opslaggrootte tot 128 TB, snel verticaal en horizontaal schalen, snel databaseherstel.
bereken grootte	2 tot 128 vCores	2 tot 128 vCores	2 tot 128 vCores
opslagtype	Premium externe opslag (per exemplaar)	Super snelle lokale SSD-opslag (per exemplaar)	Losgekoppelde opslag met lokale SSD-cache (per rekenreplica)
opslaggrootte	1 GB – 4 TB	1 GB – 4 TB	10 GB – 128 TB
IOPS	320 IOPS per vCore met maximaal 16.000 IOPS	4.000 IOPS per vCore met maximaal 327.680 IOPS	327.680 IOPS met maximale lokale SSD Hyperscale is een architectuur met meerdere lagen met caching op meerdere niveaus. Effectieve IOPS is afhankelijk van de workload.
geheugen/vCore	5,1 GB	5,1 GB	5,1 GB of 10,2 GB
Beschikbaarheid	Eén replica, geen lees schaaluitbreiding, zone-redundante hoge beschikbaarheid (HA)	Drie replica's, één uitgeschaalde, zone-redundante hoge beschikbaarheid	Meerdere replica's, maximaal vier uitschalen van leesbewerkingen, zone-redundante hoge beschikbaarheid
back-ups	Een keuze uit lokaal redundante opslag (LRS), zone-redundant (ZRS) of geografisch redundante opslag (GRS) Retentie van 1-35 dagen (standaard zeven dagen), met maximaal 10 jaar langetermijnretentie beschikbaar	Een keuze uit lokaal redundante opslag (LRS), zone-redundant (ZRS) of geografisch redundante opslag (GRS) Retentie van 1-35 dagen (standaard zeven dagen), met maximaal 10 jaar langetermijnretentie beschikbaar	Een keuze uit lokaal redundante opslag (LRS), zone-redundant (ZRS) of geografisch redundante opslag (GRS) Retentie van 1-35 dagen (standaard zeven dagen), met maximaal 10 jaar langetermijnretentie beschikbaar
prijzen/facturering	vCore, gereserveerde opslag en back-upopslag worden in rekening gebracht. IOPS worden niet in rekening gebracht.	vCore, gereserveerde opslag en back-upopslag worden in rekening gebracht. IOPS worden niet in rekening gebracht.	vCore voor elke replica, toegewezen gegevensopslag en back-upopslag worden in rekening gebracht. IOPS worden niet in rekening gebracht.
Kortingsmodellen1	gereserveerde instanties Azure Hybrid Benefit2 Enterprise en Betalen per gebruikYou-Go Dev/Test-aanbieding abonnementen	gereserveerde instanties Azure Hybrid Benefit2 Enterprise en Betalen per gebruikYou-Go Dev/Test-aanbieding abonnementen	gereserveerde instanties Azure Hybrid Benefit2 Enterprise en Betalen per gebruikYou-Go Dev/Test-aanbieding abonnementen

¹ Vereenvoudigde prijzen voor SQL Database Hyperscale zijn in december 2023 aangekomen. Raadpleeg de hyperscale-prijzenblog voor meer informatie.

² Vanaf december 2023 is Azure Hybrid Benefit niet beschikbaar voor nieuwe Hyperscale-databases of in dev/test-abonnementen. Bestaande Hyperscale-databases met ingerichte berekeningen kunnen Azure Hybrid Benefit blijven gebruiken om tot december 2026 te besparen op de rekenkosten. Raadpleeg de hyperscale-prijzenblogvoor meer informatie.

Rekenresources

Hardwareconfiguratie	Processor	Geheugen
Standard-series (Gen5)	Gereserveerde computervermogen - 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 (Milaan) processors - Maximaal 80 vCores provisioneren (hyper-threaded) serverloze rekenkracht - 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 (Milaan) processors - Automatisch schalen tot 80 vCores (hyperthreaded) - De verhouding tussen geheugen en vCore past zich dynamisch aan het geheugen- en CPU-gebruik aan op basis van de vraag naar werkbelasting en kan zo hoog zijn als 24 GB per vCore. Op een bepaald moment zou een workload bijvoorbeeld gebruik kunnen maken van 240 GB geheugen en maar 10 vCores, en daarvoor gefactureerd kunnen worden.	Gereserveerde computervermogen - 5,1 GB per vCore-eenheid - Maximaal 625 GB inrichten serverloze rekenkracht - Automatisch schalen tot 24 GB per vCore - Automatisch schalen tot maximaal 240 GB
Premium-serie	- Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC 7763v (Milaan) processors - Maximaal 128 vCores inrichten (hyperthreaded)	- 5,1 GB per vCore-eenheid
Geoptimaliseerd geheugen uit de Premium-serie	- Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC 7763v (Milaan) processors - Maximaal 80 vCores provisioneren (hyper-threaded)	- 10,2 GB per vCore

¹ In de sys.dm_user_db_resource_governance dynamische beheerweergave wordt hardwaregeneratie voor databases met Intel® SP-8160-processors (Skylake) weergegeven als Gen6, hardwaregeneratie voor databases die Gebruikmaken van Intel® 8272CL (Cascade Lake) als Gen7 en hardwaregeneratie voor databases met Intel® Xeon® Platinum 8370C (Ice Lake) of AMD® EPYC® 7763v (Milaan). Voor een bepaalde rekenkracht en hardwareconfiguratie zijn resourcelimieten hetzelfde, ongeacht het CPU-type. Zie resourcelimieten voor individuele databases en elastische poolsvoor meer informatie.

Serverloos wordt alleen ondersteund op Standard-serie (Gen5) hardware.

Hyperscale-databases maken en beheren

U kunt Hyperscale-databases maken en beheren met behulp van Azure Portal, Transact-SQL, PowerShell en de Azure CLI. Zie Quickstart: Een Hyperscale-database makenvoor meer informatie.

operatie	details	Meer informatie
Een Hyperscale-database maken	Hyperscale-databases zijn alleen beschikbaar met behulp van het aankoopmodel op basis van vCore.	Voorbeelden zoeken voor het maken van een Hyperscale-database in Quickstart: Een Hyperscale-database maken in Azure SQL Database.
een bestaande database upgraden naar Hyperscale	Het migreren van een bestaande database in Azure SQL Database naar de Hyperscale-laag is een grootte van de gegevensbewerking.	Leer hoe u een bestaande database migreert naar Hyperscale.
Een Hyperscale-database terugzetten naar de Algemene Doel servicelaag	Als u eerder een bestaande Azure SQL Database naar de Hyperscale-servicelaag hebt gemigreerd, kunt u de database binnen 45 dagen na de oorspronkelijke migratie naar Hyperscale omkeren naar de servicelaag Algemeen gebruik. Als u de database wilt migreren naar een andere servicelaag, zoals Bedrijfskritiek, moet u eerst omkeren naar de servicelaag Algemeen gebruik en vervolgens de servicelaag wijzigen.	Leer hoe u een omgekeerde migratie kunt uitvoeren vanaf Hyperscale-, inclusief de beperkingen ervan.

Beperkingen

Dit zijn de huidige beperkingen van de Hyperscale-servicelaag. We werken er actief aan om zoveel mogelijk van deze beperkingen te verwijderen.

Probleem	Beschrijving
Verkleinen wordt geblokkeerd wanneer TDE is uitgeschakeld	Op dit moment worden bewerkingen voor het verkleinen van databases en bestanden niet ondersteund wanneer Transparent Data Encryption (TDE) is uitgeschakeld in Azure SQL Database Hyperscale.
Database herstellen vanuit andere servicelagen	Een niet-Hyperscale-database kan niet worden hersteld als een Hyperscale-database en een Hyperscale-database kan niet worden hersteld als een niet-Hyperscale-database. Voor databases die zijn gemigreerd naar Hyperscale vanuit andere Azure SQL Database-servicelagen, worden back-ups vóór de migratie bewaard voor de duur van back-upretentie periode van de brondatabase, inclusief langetermijnretentiebeleid. Het herstellen van een back-up vóór de migratie binnen de bewaarperiode van de back-up van de database wordt ondersteund via de opdrachtregel. U kunt deze back-ups herstellen naar een servicelaag die niet van Hyperscale is.
Migratie van databases met In-Memory OLTP-objecten	Hyperscale ondersteunt een subset van In-Memory OLTP-objecten, waaronder tabeltypen die zijn geoptimaliseerd voor geheugen, tabelvariabelen en systeemeigen gecompileerde modules. Wanneer er echter In-Memory OLTP-objecten aanwezig zijn in de database die wordt gemigreerd, wordt migratie van Premium- en Bedrijfskritieke servicelagen naar Hyperscale niet ondersteund. Als u een dergelijke database wilt migreren naar Hyperscale, moeten alle In-Memory OLTP-objecten en de bijbehorende afhankelijkheden worden verwijderd. Nadat de database is gemigreerd, kunnen deze objecten opnieuw worden gemaakt. Duurzame en niet-duurzame tabellen die zijn geoptimaliseerd voor geheugen worden momenteel niet ondersteund in Hyperscale en moeten worden gewijzigd in schijftabellen.
Controle van databaseintegriteit	DBCC CHECKDB wordt momenteel niet ondersteund voor Hyperscale-databases. DBCC CHECKTABLE ('TableName') MET TABLOCK en DBCC CHECKFILEGROUP MET TABLOCK kan worden gebruikt als tijdelijke oplossing. Zie Gegevensintegriteit in Azure SQL Database voor meer informatie over gegevensintegriteitsbeheer in Azure SQL Database.
Elastische taken	Het gebruik van een Hyperscale-database als taakdatabase wordt niet ondersteund. Elastische taken kunnen echter hyperscale databases net zo goed aansturen als elke andere database in Azure SQL Database.
Gegevenssynchronisatie	Het gebruik van een Hyperscale-database als hub- of synchronisatiemetagegevensdatabase wordt niet ondersteund. Een Hyperscale-database kan echter een liddatabase zijn in een Data Sync-topologie.
Hardware van de Hyperscale-servicelaag premium-serie	Hardware uit de Premium-serie en geheugen-geoptimaliseerde Premium-serie biedt momenteel geen ondersteuning voor de serverloze rekenlaag.
Regionale beschikbaarheid	De hyperscale-servicelaag premium-serie en de geheugen-geoptimaliseerde premium-serie hardware zijn beschikbaar in beperkte Azure-regio's. Zie beschikbaarheid van de Hyperscale Premium-serievoor een lijst.

Verwante inhoud

• Veelgestelde vragen over Hyperscale
• Vergelijk de op vCore en DTU gebaseerde aankoopmodellen van Azure SQL Database
• Resourcebeheer in Azure SQL Database
• resourcelimieten voor individuele databases met behulp van het vCore-aankoopmodel
• vergelijking van -functies: Azure SQL Database en Azure SQL Managed Instance
• Hyperscale-architectuur voor gedistribueerde functies
• Een Hyperscale-database beheren