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 het aankoopmodel op basis van vCore en vergelijk aankoopmodellen voor meer informatie.
DTU's (Database Transaction Units)
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 rekenkracht met minimale downtime. Er is echter een switch over een periode waarin de verbinding met de database gedurende 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 één database met een specifieke rekenkracht binnen een servicelaag garandeert Azure SQL Database een bepaald niveau van resources voor die database (onafhankelijk van een andere database). Deze garantie biedt een voorspelbaar prestatieniveau. De hoeveelheid resources die voor een database zijn 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 zijn de resources die door uw workload worden gebruikt, niet van invloed op de resources die beschikbaar zijn voor andere databases in de Azure-cloud. Op dezelfde manier hebben de resources die door andere workloads worden gebruikt, geen invloed op de resources die beschikbaar zijn voor uw database.
DTU's zijn het handigst om inzicht te krijgen in de relatieve resources die zijn toegewezen voor databases met verschillende rekengrootten en servicelagen. Voorbeeld:
- Het verdubbelen van de DTU's door de rekenkracht van een database te vergroten, komt overeen met het verdubbelen van de set resources die beschikbaar zijn voor die database.
- Een P11-database van 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 DTU-verbruik (resourceverbruik) van uw workload, gebruikt u inzichten in queryprestaties om:
- Identificeer de belangrijkste query's op basis van CPU/duur/uitvoeringsaantal dat mogelijk kan worden afgestemd op verbeterde prestaties. Een I/O-intensieve query kan bijvoorbeeld baat hebben bij optimalisatietechnieken in het geheugen om beter gebruik te maken van het beschikbare geheugen op een bepaalde servicelaag en rekenkracht.
- Inzoomen op de details van een query om de tekst en de geschiedenis van het resourcegebruik weer te geven.
- Bekijk aanbevelingen voor het afstemmen van prestaties die acties weergeven die zijn uitgevoerd door SQL Database Advisor.
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 kunnen worden gebruikt door één database in de pool, 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 worden geschaald binnen de geconfigureerde grenzen. Een database onder 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 meer eDTU's toevoegen aan een bestaande pool met minimale downtime van de database. Als u 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-databases 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 elastische SQL Database-pool overwegen voor meer informatie.
Het aantal DTU's bepalen dat nodig is voor een workload
Als u een bestaande workload van een on-premises of virtuele SQL Server-machine wilt migreren naar SQL Database, raadpleegt u SKU-aanbevelingen om het aantal benodigde DTU's bij benadering te bepalen. Voor een bestaande SQL Database-workload gebruikt u inzichten in queryprestaties om inzicht te krijgen in uw DTU's (Database-Resource Consumption) en om meer inzicht te krijgen in het optimaliseren van uw workload. Met de sys.dm_db_resource_stats dynamische beheerweergave (DMV) kunt u het resourceverbruik voor het afgelopen uur bekijken. In de weergave sys.resource_stats catalogus wordt het resourceverbruik voor de afgelopen 14 dagen weergegeven, maar met een lagere kwaliteit van gemiddelden van vijf minuten.
DTU-gebruik bepalen
Gebruik de volgende formule om het gemiddelde percentage 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 DTU/eDTU-gebruik te bepalen voor 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 al het beschikbare geheugen voor de gegevenscache gebruikt om de prestaties te verbeteren, is de avg_memory_usage_percent waarde meestal bijna 100 procent, ongeacht de huidige databasebelasting. Hoewel geheugen indirect invloed heeft op de DTU-limiet, wordt deze dus niet gebruikt in de formule DTU-gebruik.
Hardwareconfiguratie
In het aankoopmodel op basis van DTU kunnen klanten niet de hardwareconfiguratie kiezen die voor hun databases wordt gebruikt. Hoewel een bepaalde database meestal gedurende lange tijd op een specifiek type hardware blijft (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 buiten gebruik wordt gesteld vanwege het einde van de levensduur.
Als een database naar verschillende hardware wordt verplaatst, kunnen de prestaties van de werkbelasting veranderen. Het DTU-model garandeert dat de doorvoer- en reactietijd van de DTU-benchmarkworkload aanzienlijk identiek blijven wanneer de database naar een ander hardwaretype wordt verplaatst, 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. Voor andere workloads dan de DTU-benchmark is het daarom 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.
| Basis | Standaard | Premium | |
|---|---|---|---|
| Doelworkload | Ontwikkeling en productie | Ontwikkeling en productie | Ontwikkeling en productie |
| Uptime SLA | 99,99% | 99,99% | 99,99% |
| Een back-up maken | Een keuze uit geografisch redundante, zone-redundante of lokaal redundante back-upopslag, retentie van 1-7 dagen (standaard 7 dagen) Langetermijnretentie beschikbaar tot 10 jaar |
Een keuze uit geografisch redundante, zone-redundante of lokaal redundante back-upopslag, retentie van 1-35 dagen (standaard 7 dagen) Langetermijnretentie beschikbaar tot 10 jaar |
Een keuze uit lokaal redundante opslag (LRS), zone-redundant (ZRS) of geografisch redundante opslag (GRS) Retentie van 1-35 dagen (standaard 7 dagen), met maximaal 10 jaar langetermijnretentie beschikbaar |
| CPU | Laag | Laag, Gemiddeld, Hoog | Gemiddeld, Hoog |
| IOPS (bij benadering)* | 1-4 IOPS per DTU | 1-4 IOPS per DTU | >25 IOPS per DTU |
| IO-latentie (geschatte) | 5 ms (lezen), 10 ms (schrijven) | 5 ms (lezen), 10 ms (schrijven) | 2 ms (lezen/schrijven) |
| Columnstore-indexering | N.v.t. | Standard S3 en hoger | Ondersteund |
| OLTP in het geheugen | N.v.t. | N.v.t. | Ondersteund |
* Alle IOPS voor lezen en schrijven op gegevensbestanden, inclusief 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 schijven (HDD). Deze servicedoelstellingen zijn het meest geschikt voor ontwikkeling, testen en andere niet-frequent geopende workloads die minder gevoelig zijn voor de variabiliteit van de prestaties.
Fooi
Als u de werkelijke limieten voor resourcebeheer voor een database of elastische pool wilt bekijken, voert u een query uit op de sys.dm_user_db_resource_governance weergave. Voor één database wordt één rij geretourneerd. Voor een database in een elastische pool wordt een rij geretourneerd voor elke database in de pool.
Notitie
U kunt een gratis database in Azure SQL Database verkrijgen in de Basic-servicelaag met een gratis Azure-account. Zie Een beheerde clouddatabase maken met uw gratis Azure-account voor meer informatie.
Bronlimieten
Resourcelimieten verschillen voor individuele en pooldatabases.
Opslaglimieten voor individuele databases
In Azure SQL Database worden rekengrootten uitgedrukt in DTU's (Database Transaction Units) voor individuele databases en eDTU's (Elastic Database Transaction Units) voor elastische pools. Raadpleeg de resourcelimieten voor individuele databases voor meer informatie.
| Basis | Standaard | 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 | Standaard | 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, met uitzondering van: 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 aan elke DTU-meting zijn gekoppeld, 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 het vCore-aankoopmodel voor Azure SQL Database onafhankelijk reken- en opslagresources kiezen en schalen.
Met het aankoopmodel op basis van vCore kunt u ook Azure Hybrid Benefit voor SQL Server gebruiken 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:
- Zie resourcelimieten op basis van SQL Database DTU voor individuele databases voor meer informatie over specifieke rekengrootten en opslaggrootten die beschikbaar zijn voor individuele databases.
- Zie resourcelimieten op basis van SQL Database DTU voor meer informatie over specifieke rekengrootten en opslaggrootten die beschikbaar zijn voor elastische pools.
- Zie de DTU-benchmark voor informatie over de benchmark die is gekoppeld aan het aankoopmodel op basis van DTU.
- Vergelijk vCore- en DTU-aankoopmodellen van Azure SQL Database.