Overzicht van aankoopmodel op basis van DTU

Van toepassing op: Azure SQL-database

In dit artikel vindt u meer informatie over het aankoopmodel op basis van DTU voor Azure SQL Database.

Bekijk voor meer informatie het aankoopmodel op basis van vCore en vergelijk aankoopmodellen.

Database transaction units (DTU's)

Een DTU (Database Transaction Unit) vertegenwoordigt een gecombineerde meting van CPU, geheugen en lees- en schrijfbewerkingen. Servicelagen in het aankoopmodel op basis van DTU worden onderscheiden door een reeks rekengrootten met een vaste hoeveelheid inbegrepen opslag, vaste bewaarperiode voor back-ups en vaste prijs. Alle servicelagen in het aankoopmodel op basis van DTU bieden flexibiliteit bij het wijzigen van rekengrootten met minimale downtime; Er is echter een overschakeling in de loop van de periode waarbij de verbinding met de database gedurende een korte tijd verloren gaat, wat kan worden beperkt met behulp van logica voor opnieuw proberen. Individuele databases en elastische pools worden elk uur gefactureerd op basis van de servicelaag en rekenkracht.

Voor een individuele database met een specifieke rekenkracht binnen een servicelaag garandeert Azure SQL Database een bepaald niveau van resources voor die database garandeert (onafhankelijk van een andere database). Deze garantie biedt een voorspelbaar prestatieniveau. De hoeveelheid resources die voor een database worden toegewezen, wordt berekend als een aantal DTU's en is een gebundelde meting van reken-, opslag- en I/O-resources.

De verhouding tussen deze resources wordt oorspronkelijk bepaald door een OLTP-benchmarkworkload (Online Transaction Processing) die is ontworpen om typisch te zijn voor echte OLTP-workloads. Wanneer uw workload de hoeveelheid van deze resources overschrijdt, wordt uw doorvoer beperkt, wat resulteert in tragere prestaties en time-outs.

Voor individuele databases hebben de resources die door uw workload worden gebruikt, geen invloed op de resources die beschikbaar zijn voor andere databases in de Azure-cloud. De resources die door andere workloads worden gebruikt, hebben ook geen invloed op de resources die beschikbaar zijn voor uw database.

Begrenzingsvak

DTU's zijn het handigst om inzicht te krijgen in de relatieve resources die zijn toegewezen voor databases in verschillende rekengrootten en servicelagen. Bijvoorbeeld:

  • Het verdubbelen van de DTU's door de rekenkracht van een database te vergroten, is gelijk aan het verdubbelen van de set resources die beschikbaar zijn voor die database.
  • Een P11-database met een Premium-servicelaag met 1750 DTU's biedt 350 keer meer DTU-rekenkracht dan een basic servicelaagdatabase met 5 DTU's.

Als u meer inzicht wilt krijgen in het resourceverbruik (DTU) van uw workload, gebruikt u inzichten in queryprestaties om het volgende te doen:

  • Identificeer de belangrijkste query's op CPU/duur/uitvoeringsaantal dat mogelijk kan worden afgestemd op verbeterde prestaties. Een I/O-intensieve query kan bijvoorbeeld profiteren van optimalisatietechnieken in het geheugen om beter gebruik te maken van het beschikbare geheugen in een bepaalde servicelaag en rekenkracht.
  • Inzoomen op de details van een query om de tekst en de geschiedenis van het resourcegebruik te bekijken.
  • Aanbevelingen voor het afstemmen van prestaties openen die door SQL Database Advisor worden uitgevoerd.

EDTU's (Elastic Database Transaction Units)

In plaats van een toegewezen set resources (DTU's) te bieden die mogelijk niet altijd nodig zijn, kunt u deze databases in een elastische pool plaatsen. De databases in een elastische pool gebruiken één exemplaar van de database-engine en delen dezelfde groep resources.

De gedeelde resources in een elastische pool worden gemeten door eDTU's (Elastic Database Transaction Units). Elastische pools bieden een eenvoudige, rendabele oplossing voor het beheren van prestatiedoelen voor meerdere databases met veel verschillende en onvoorspelbare gebruikspatronen. Een elastische pool garandeert dat alle resources niet door één database in de pool kunnen worden gebruikt, terwijl ervoor wordt gezorgd dat elke database in de pool altijd een minimale hoeveelheid benodigde resources heeft.

Een groep krijgt een vast aantal eDTU's voor een vaste prijs. In de elastische pool kunnen afzonderlijke databases automatisch schalen binnen de geconfigureerde grenzen. Een database met een zwaardere belasting verbruikt meer eDTU's om aan de vraag te voldoen. Databases onder lichtere belastingen verbruiken minder eDTU's. Databases zonder belasting verbruiken geen eDTU's. Omdat resources worden ingericht voor de hele pool, in plaats van per database, vereenvoudigen elastische pools uw beheertaken en bieden ze een voorspelbaar budget voor de pool.

U kunt extra eDTU's toevoegen aan een bestaande pool met minimale downtime van de database. Als u ook geen extra eDTU's meer nodig hebt, verwijdert u deze op elk gewenst moment uit een bestaande pool. U kunt ook op elk gewenst moment databases toevoegen aan of verwijderen uit een pool. Als u eDTU's voor andere databases wilt reserveren, beperkt u het aantal eDTU's dat kan worden gebruikt onder een zware belasting. Als een database consistent hoog resourcegebruik heeft dat van invloed is op andere databases in de pool, verplaatst u deze uit de pool en configureert u deze als één database met een voorspelbare hoeveelheid vereiste resources.

Workloads die profiteren van een elastische pool met resources

Pools zijn zeer geschikt voor databases met een laag resourcegebruiksgemiddelde en relatief onregelmatige gebruikspieken. Zie Wanneer moet u een SQL Database elastische pool overwegen voor meer informatie.

Het aantal DTU's bepalen dat nodig is voor een workload

Als u een bestaande on-premises workload of SQL Server virtuele machine naar SQL Database wilt migreren, raadpleegt u SKU-aanbevelingen om het aantal benodigde DTU's bij te houden. Gebruik voor een bestaande SQL Database workload inzichten in queryprestaties om inzicht te krijgen in uw databaseresourceverbruik (DTU's) en meer inzicht te krijgen in het optimaliseren van uw workload. Met de sys.dm_db_resource_stats dynamische beheerweergave (DMV) kunt u het resourceverbruik van het afgelopen uur bekijken. In de weergave sys.resource_stats catalogus wordt het resourceverbruik voor de afgelopen 14 dagen weergegeven, maar met een lagere betrouwbaarheid van gemiddelden van vijf minuten.

DTU-gebruik bepalen

Gebruik de volgende formule om het gemiddelde percentage van het DTU/eDTU-gebruik te bepalen ten opzichte van de DTU/eDTU-limiet van een database of een elastische pool:

avg_dtu_percent = MAX(avg_cpu_percent, avg_data_io_percent, avg_log_write_percent)

De invoerwaarden voor deze formule kunnen worden verkregen uit sys.dm_db_resource_stats, sys.resource_stats en sys.elastic_pool_resource_stats DMV's. Met andere woorden, om het percentage van het DTU/eDTU-gebruik te bepalen ten opzichte van de DTU/eDTU-limiet van een database of een elastische pool, kiest u de grootste percentagewaarde uit het volgende: avg_cpu_percent, avg_data_io_percenten avg_log_write_percent op een bepaald tijdstip.

Notitie

De DTU-limiet van een database wordt bepaald door CPU, leesbewerkingen, schrijfbewerkingen en geheugen die beschikbaar zijn voor de database. Omdat de SQL Database-engine doorgaans echter alle beschikbare geheugen voor de gegevenscache gebruikt om de prestaties te verbeteren, is de waarde meestal bijna 100 procent, ongeacht de avg_memory_usage_percent huidige databasebelasting. Hoewel het geheugen indirect invloed heeft op de DTU-limiet, wordt het dus niet gebruikt in de DTU-gebruiksformule.

Hardwareconfiguratie

In het aankoopmodel op basis van DTU kunnen klanten niet de hardwareconfiguratie kiezen die wordt gebruikt voor hun databases. Hoewel een bepaalde database meestal gedurende lange tijd op een specifiek type hardware blijft staan (meestal voor meerdere maanden), zijn er bepaalde gebeurtenissen die ertoe kunnen leiden dat een database naar verschillende hardware wordt verplaatst.

Een database kan bijvoorbeeld worden verplaatst naar verschillende hardware als deze omhoog of omlaag wordt geschaald naar een andere servicedoelstelling, of als de huidige infrastructuur in een datacenter de capaciteitslimieten nadert of als de momenteel gebruikte hardware wordt buiten gebruik gesteld vanwege het einde van de levensduur.

Als een database naar verschillende hardware wordt verplaatst, kunnen de prestaties van workloads veranderen. Het DTU-model garandeert dat de doorvoer- en reactietijd van de DTU-benchmarkworkload aanzienlijk identiek blijven wanneer de database wordt verplaatst naar een ander hardwaretype, zolang de servicedoelstelling (het aantal DTU's) hetzelfde blijft.

In het brede spectrum van klantworkloads die worden uitgevoerd in Azure SQL Database, kan de impact van het gebruik van verschillende hardware voor dezelfde servicedoelstelling echter duidelijker zijn. Verschillende workloads kunnen profiteren van verschillende hardwareconfiguraties en -functies. Daarom is het voor andere workloads dan de DTU-benchmark mogelijk om prestatieverschillen te zien als de database van het ene type hardware naar het andere wordt verplaatst.

Klanten kunnen het vCore-model gebruiken om hun voorkeurshardwareconfiguratie te kiezen tijdens het maken en schalen van de database. In het vCore-model worden gedetailleerde resourcelimieten van elke servicedoelstelling in elke hardwareconfiguratie gedocumenteerd voor individuele databases en elastische pools. Zie Hardwareconfiguratie voor SQL Database of Hardwareconfiguratie voor SQL Managed Instance voor meer informatie over hardware in het vCore-model.

Servicelagen vergelijken

Het kiezen van een servicelaag is voornamelijk afhankelijk van bedrijfscontinuïteit, opslag en prestatievereisten.

Basic Standard Premium
Doelworkload Ontwikkeling en productie Ontwikkeling en productie Ontwikkeling en productie
Uptime SLA 99,99% 99,99% 99,99%
Maximale retentie van back-ups 7 dagen 35 dagen 35 dagen
CPU Beperkt Laag, Gemiddeld, Hoog Gemiddeld, hoog
IOPS (bij benadering)* 1-4 IOPS per DTU 1-4 IOPS per DTU >25 IOPS per DTU
IO-latentie (bij benadering) 5 ms (lezen), 10 ms (schrijven) 5 ms (lezen), 10 ms (schrijven) 2 ms (lezen/schrijven)
Columnstore-indexering N.v.t. S3 en hoger Ondersteund
OLTP in het geheugen N.v.t. N.v.t. Ondersteund

* Alle IOPS lezen en schrijven op basis van gegevensbestanden, waaronder achtergrond-IO (controlepunt en luie schrijver)

Belangrijk

De servicedoelstellingen Basic, S0, S1 en S2 bieden minder dan één vCore (CPU). Voor CPU-intensieve workloads wordt een servicedoelstelling van S3 of hoger aanbevolen.

In de servicedoelstellingen Basic, S0 en S1 worden databasebestanden opgeslagen in Azure Standard Storage, die gebruikmaakt van opslagmedia op basis van harde schijf (HDD). Deze servicedoelstellingen zijn het meest geschikt voor ontwikkeling, testen en andere onregelmatig geopende workloads die minder gevoelig zijn voor de variabiliteit van de prestaties.

Tip

Als u de werkelijke limieten voor resourcebeheer voor een database of elastische pool wilt zien, voert u een query uit op de sys.dm_user_db_resource_governance weergave.

Notitie

U kunt een gratis database verkrijgen in Azure SQL Database in de servicelaag Basic in combinatie met een gratis Azure-account om Azure te verkennen. Zie Een beheerde clouddatabase maken met uw gratis Azure-account voor meer informatie.

Bronlimieten

Resourcelimieten verschillen voor individuele en pooldatabases.

Opslaglimieten voor individuele databases

Rekengrootten worden uitgedrukt in DTU's (Database Transaction Units) voor individuele databases en eDTU's (Elastic Database Transaction Units) voor elastische pools. Raadpleeg resourcelimieten voor individuele databases voor meer informatie.

Basic Standard Premium
Maximale opslaggrootte 2 GB 1 TB 4 TB
Maximum aantal DTU's 5 3000 4000

Belangrijk

In sommige gevallen moet u mogelijk een database verkleinen om ongebruikte ruimte vrij te maken. Zie Bestandsruimte beheren in Azure SQL Database voor meer informatie.

Limieten voor elastische pools

Raadpleeg de resourcelimieten voor pooldatabases voor meer informatie.

Basic Standard Premium
Maximale opslaggrootte per database 2 GB 1 TB 1 TB
Maximale opslaggrootte per pool 156 GB 4 TB 4 TB
Maximum aantal eDTU's per database 5 3000 4000
Maximum aantal eDTU's per pool 1600 3000 4000
Maximum aantal databases per pool 500 500 100

Belangrijk

Meer dan 1 TB opslagruimte in de Premium-laag is momenteel beschikbaar in alle regio's, behalve: China - oost, China - noord, Duitsland - centraal en Duitsland - noordoost. In deze regio’s is de maximale opslagruimte in de Premium-laag beperkt tot 1 TB. Raadpleeg P11-P15 huidige beperkingen voor meer informatie.

Belangrijk

In sommige gevallen moet u mogelijk een database verkleinen om ongebruikte ruimte vrij te maken. Zie bestandsruimte beheren in Azure SQL Database voor meer informatie.

DTU-benchmark

Fysieke kenmerken (CPU, geheugen, IO) die zijn gekoppeld aan elke DTU-meting, worden gekalibreerd met behulp van een benchmark die de werkelijke databaseworkload simuleert.

Meer informatie over het schema, gebruikte transactietypen, workloadmix, gebruikers en pacing, schaalregels en metrische gegevens die zijn gekoppeld aan de DTU-benchmark.

Aankoopmodellen op basis van DTU en vCore vergelijken

Hoewel het aankoopmodel op basis van DTU is gebaseerd op een gebundelde meting van reken-, opslag- en I/O-resources, kunt u met vergelijking het vCore-aankoopmodel voor Azure SQL Database onafhankelijk kiezen en schalen van reken- en opslagresources.

Met het aankoopmodel op basis van vCore kunt u ook Azure Hybrid Benefit gebruiken voor SQL Server om kosten te besparen en biedt serverloze en Hyperscale-opties voor Azure SQL Database die niet beschikbaar zijn in het aankoopmodel op basis van DTU.

Meer informatie over het vergelijken van vCore- en DTU-aankoopmodellen van Azure SQL Database.

Volgende stappen

Meer informatie over aankoopmodellen en gerelateerde concepten vindt u in de volgende artikelen: