Kiezen tussen de aankoopmodellen vCore en DTU - Azure SQL Database en SQL Managed Instance
VAN TOEPASSING OP: 
Azure SQL Database
Azure SQL Managed Instance
Azure SQL Database en Azure SQL Managed Instance kunt u eenvoudig een volledig beheerde platform as a service(PaaS)-database-engine aanschaffen die past bij uw prestatie- en kostenbehoeften. Afhankelijk van het implementatiemodel dat u hebt gekozen voor Azure SQL Database, kunt u het aankoopmodel selecteren dat voor u werkt:
- Aankoopmodel op basis van virtuele kern (vCore) (aanbevolen). Dit aankoopmodel biedt een keuze tussen een inrichtende rekenlaag en een serverloze rekenlaag. Met de inrichtende rekenlaag kiest u de exacte hoeveelheid rekenbronnen die altijd zijn ingericht voor uw workload. Met de serverloze rekenlaag geeft u de automatische schalen van de rekenresources op via een configureerbaar rekenbereik. Met deze rekenlaag kunt u de database ook automatisch onderbreken en hervatten op basis van workloadactiviteit. De prijs van de vCore-eenheid per tijdseenheid is lager in de inrichtende rekenlaag dan in de serverloze rekenlaag.
- Aankoopmodel op basis van databasetransactie-eenheid (DTU). Dit aankoopmodel biedt gebundelde reken- en opslagpakketten die in balans zijn voor algemene workloads.
Er zijn twee aankoopmodellen:
- Het aankoopmodel op basis van vCore is beschikbaar voor zowel Azure SQL Database als Azure SQL Managed Instance. De Hyperscale-servicelaag is beschikbaar voor individuele databases die gebruikmaken van het aankoopmodel op basis van vCore.
- Aankoopmodel op basis van DTU is beschikbaar voor Azure SQL Database.
In de volgende tabel en grafiek worden de aankoopmodellen op basis van vCore en DTU vergeleken en vergeleken:
| Aankoopmodel | Beschrijving | Ideaal voor |
|---|---|---|
| Op basis van DTU | Dit model is gebaseerd op een gebundelde meting van reken-, opslag- en I/O-resources. Rekengrootten worden uitgedrukt in DTU's voor afzonderlijke databases, en in EDTU's (Elastische Data Transaction Unit) voor elastische pools. Zie Wat zijn DTU's en EDTU's voor meer informatie over DTU's en EDTU's. | Klanten die eenvoudige, vooraf geconfigureerde resourceopties willen |
| Op vCore gebaseerd | Met dit model kunt u onafhankelijk reken- en opslagbronnen kiezen. Met het op vCore gebaseerde aankoopmodel kunt u ook Azure Hybrid Benefit gebruiken voor SQL Server, om kosten te besparen. | Klanten die flexibiliteit, controle en transparantie waarderen |
Wilt u uw clouduitgaven optimaliseren en geld besparen?
Azure-services kosten geld. Azure Cost Management helpt u om budgetten op te stellen en waarschuwingen te configureren om uw uitgaven onder controle te houden. Analyseer, beheer en optimaliseer uw Azure-kosten met Cost Management. Raadpleeg voor meer informatie de snelstartgids over de analyse van uw kosten.
Rekenkosten
Inrichten van rekenkosten
In de inrichtende rekenlaag weerspiegelen de rekenkosten de totale rekencapaciteit die voor de toepassing is ingericht.
In de Bedrijfskritiek servicelaag wijzen we automatisch ten minste drie replica's toe. Om deze extra toewijzing van rekenbronnen weer te geven, is de prijs in het aankoopmodel op basis van vCore ongeveer 2,7 keer hoger in de Bedrijfskritiek-servicelaag dan in de Algemeen-servicelaag. Evenzo weerspiegelt de hogere opslagprijs per GB in de Bedrijfskritiek-servicelaag de hogere I/O-limieten en lagere latentie van de SSD-opslag.
De kosten voor back-upopslag zijn hetzelfde voor de Bedrijfskritiek-servicelaag en de Algemeen-servicelaag, omdat beide lagen standaardopslag voor back-ups gebruiken.
Serverloze rekenkosten
Zie serverloze laag voor een beschrijving van hoe de rekencapaciteit wordt gedefinieerd en de kosten worden berekend voor de SQL Database serverloze rekenlaag.
Opslagkosten
Verschillende typen opslag worden anders gefactureerd. Voor gegevensopslag worden kosten in rekening gebracht voor de ingerichte opslag op basis van de maximale database- of poolgrootte die u selecteert. De kosten veranderen alleen als u dat maximum verlaagt of verhoogt. Back-upopslag is gekoppeld aan automatische back-ups van uw exemplaar en wordt dynamisch toegewezen. Als u de bewaarperiode voor back-ups verhoogt, wordt de back-upopslag die door uw exemplaar wordt gebruikt, verhoogd.
Standaard worden zeven dagen aan automatische back-ups van uw databases gekopieerd naar een standaard Blob Storage-account met leestoegang (RA-GRS). Deze opslag wordt gebruikt door wekelijkse volledige back-ups, dagelijkse differentiële back-ups en transactielogboekback-ups, die elke vijf minuten worden gekopieerd. De grootte van de transactielogboeken is afhankelijk van de wijzigingssnelheid van de database. Er wordt zonder extra kosten een minimaal opslagbedrag geboden dat gelijk is aan 100 procent van de databasegrootte. Extra verbruik van back-upopslag wordt in GB per maand in rekening gebracht.
Zie de pagina met prijzen voor meer informatie over opslagprijzen.
Aankoopmodel op basis van vCore
Een virtuele kern (vCore) vertegenwoordigt een logische CPU en biedt u de mogelijkheid om te kiezen tussen generaties hardware en de fysieke kenmerken van de hardware (bijvoorbeeld het aantal kernen, het geheugen en de opslaggrootte). Het aankoopmodel op basis van vCore biedt u flexibiliteit, controle, transparantie van het gebruik van afzonderlijke resources en een eenvoudige manier om vereisten voor on-premises workloads te vertalen naar de cloud. Met dit model kunt u reken-, geheugen- en opslagbronnen kiezen op basis van uw workloadbehoeften.
In het aankoopmodel op basis van vCore kunt u kiezen tussen de Algemeen- en Bedrijfskritiek-servicelagen voor SQL Database en SQL Managed Instance. Voor individuele databases kunt u ook de Hyperscale-servicelaag kiezen.
Met het aankoopmodel op basis van vCore kunt u onafhankelijk reken- en opslagbronnen kiezen, on-premises prestaties matchen en de prijs optimaliseren. In het aankoopmodel op basis van vCore betaalt u voor:
- Rekenbronnen (de servicelaag, het aantal vCores, de hoeveelheid geheugen en de generatie van de hardware).
- Het type en de hoeveelheid gegevens- en logboekopslag.
- Back-upopslag (RA-GRS).
Belangrijk
Rekenbronnen, I/O en gegevens- en logboekopslag worden in rekening gebracht per database of elastische pool. Back-upopslag wordt per database in rekening gebracht. Zie Beheerd exemplaar SQL meer informatie over SQL managed instance. Regiobeperkingen: Zie Beschikbare producten per regio voor de huidige lijst met ondersteunde regio's. Als u een beheerd exemplaar wilt maken in een regio die momenteel niet wordt ondersteund, verzendt u een ondersteuningsaanvraag via de Azure Portal.
Als uw database meer dan 300 DTUs verbruikt, kunt u uw kosten verlagen door te converteren naar het aankoopmodel op basis van vCore. U kunt converteren met behulp van de API van uw keuze of met behulp van Azure Portal, zonder downtime. Conversie is echter niet vereist en wordt niet automatisch uitgevoerd. Als het aankoopmodel op basis van DTU voldoet aan uw prestatie- en bedrijfsvereisten, moet u het blijven gebruiken.
Zie Migrate from DTU to vCore(Migreren van DTU naar vCore) als u wilt converteren van het aankoopmodel op basis van DTU naar het aankoopmodel op basis van vCore.
Aankoopmodel op basis van DTU
Een DTU (Database Transaction Unit) vertegenwoordigt een gecombineerde meting van CPU, geheugen en lees- en schrijfbewerkingen. Het aankoopmodel op basis van DTU biedt een set vooraf geconfigureerde bundels rekenbronnen en inbegrepen opslag voor verschillende niveaus van toepassingsprestaties. Als u de voorkeur geeft aan de eenvoud van een vooraf geconfigureerde bundel en vaste betalingen per maand, is het DTU-model mogelijk beter geschikt voor uw behoeften.
In het aankoopmodel op basis van DTU kunt u kiezen tussen de servicelagen Basic, Standard en Premium voor Azure SQL Database. Het aankoopmodel op basis van DTU is niet beschikbaar voor Azure SQL Managed Instance.
Database transaction units (DTUs)
Voor één database met een specifieke rekenkracht binnen een servicelaaggarandeert Azure een bepaald niveau van resources voor die database (onafhankelijk van een andere database in de Azure-cloud). Deze garantie biedt een voorspelbaar prestatieniveau. De hoeveelheid toegewezen resources voor een database wordt berekend als een aantal DTUs 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 een typische OLTP-workload te zijn. Wanneer uw workload de hoeveelheid van deze resources overschrijdt, wordt uw doorvoer beperkt, wat resulteert in tragere prestaties en time-outs.
De resources die door uw workload worden gebruikt, hebben 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.
DTUs zijn het handigst om inzicht te krijgen in de relatieve resources die worden toegewezen voor databases met verschillende rekenkracht en servicelagen. Bijvoorbeeld:
- Het verdubbelen van de DTUs 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 van de 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 inzicht in queryprestaties voor het volgende:
- Identificeer de belangrijkste query's op CPU/duur/aantal uitvoeringen die mogelijk kunnen 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.
- Zoom in op de details van een query om de tekst en de geschiedenis van het resourcegebruik weer te geven.
- Krijg toegang tot aanbevelingen voor het afstemmen van de prestaties die acties tonen die worden SQL Database Advisor.
EDTUs (Elastic Database Transaction Units)
Voor databases die altijd beschikbaar zijn, in plaats van een toegewezen set resources (DTE's) op te geven die mogelijk niet altijd nodig zijn, kunt u deze databases in een elastische pool plaatsen. De databases in een elastische pool staan op één server en delen een groep resources.
De gedeelde resources in een elastische pool worden gemeten door eDTUs (Elastic Database Transaction Units). Elastische pools bieden een eenvoudige, rendabele oplossing voor het beheren van prestatiedoelen voor meerdere databases met uiteenlopende en onvoorspelbare gebruikspatronen. Een elastische pool garandeert dat niet alle resources door één database in de pool kunnen worden gebruikt, terwijl ervoor wordt gezorgd dat elke database in de pool altijd over een minimum aan benodigde resources beschikt.
Een pool krijgt een vast aantal eDTUs voor een bepaalde prijs. In de elastische pool kunnen afzonderlijke databases automatisch worden geschaald binnen de geconfigureerde grenzen. Een database met een zwaardere belasting verbruikt meer eDTUs om aan de vraag te voldoen. Databases met lichtere belasting verbruiken minder eDTUs. Databases zonder belasting verbruiken geen eDTUs. 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 eDTUs toevoegen aan een bestaande pool zonder databaseuitvaltijd en zonder gevolgen voor de databases in de pool. En als u geen extra eDTUs meer nodig hebt, verwijdert u ze op elk moment uit een bestaande pool. U kunt ook databases toevoegen aan of op elk moment aftrekken van een pool. Als u eDTUs wilt reserveren voor andere databases, beperkt u het aantal eDTUs dat een database kan gebruiken bij een zware belasting. Als een database consistent te veel resources gebruikt, verplaatst u deze uit de pool en configureert u deze als een individuele database met een voorspelbare hoeveelheid vereiste resources.
Het aantal DTUs bepalen dat nodig is voor een workload
Als u een bestaande workload van een on-premises of SQL Server virtuele machine wilt migreren naar SQL Database, gebruikt u de DTU-calculator om een schatting te maken van het aantal benodigde DTU's. Voor een bestaande SQL Database-workload gebruikt u inzichten in queryprestaties om inzicht te krijgen in het verbruik van databaseresources (DTUs) en diepere inzichten te verkrijgen voor het optimaliseren van uw workload. Met sys.dm_db_resource_stats dynamische beheerweergave (DMV) kunt u het resourceverbruik van het afgelopen uur bekijken. De sys.resource_stats catalogusweergave geeft het resourceverbruik weer voor de afgelopen 14 dagen, maar met een lagere betrouwbaarheid van gemiddelden van vijf minuten.
DTU-gebruik bepalen
Gebruik de volgende formule om het gemiddelde percentage DTU/eDTU-gebruik ten opzichte van de DTU/eDTU-limiet van een database of elastische pool te bepalen:
avg_dtu_percent = MAX(avg_cpu_percent, avg_data_io_percent, avg_log_write_percent)
De invoerwaarden voor deze formule kunnen worden verkregen van sys.dm_db_resource_stats, sys.resource_statsen sys.elastic_pool_resource_stats DMV's. Met andere woorden, als u het percentage DTU/eDTU-gebruik ten opzichte van de DTU/eDTU-limiet van een database of elastische pool wilt bepalen, kiest u het grootste percentage uit de volgende waarden: , en op een bepaald avg_cpu_percent avg_data_io_percent avg_log_write_percent tijdstip.
Notitie
De DTU-limiet van een database wordt bepaald door de CPU, lees-, schrijf- en geheugengegevens die beschikbaar zijn voor de database. Omdat de SQL Database-engine doorgaans alle beschikbare geheugen voor de gegevenscache gebruikt om de prestaties te verbeteren, is de waarde meestal dicht bij 100 procent, ongeacht de huidige avg_memory_usage_percent databasebelasting. Hoewel geheugen indirect van invloed is op de DTU-limiet, wordt het dus niet gebruikt in de DTU-gebruiksformule.
Workloads die profiteren van een elastische pool met resources
Pools zijn zeer geschikt voor databases met een laag gemiddeld resourcegebruik en relatief weinig pieken in het gebruik. Zie Wanneer moet u een elastische pool gebruiken voor SQL Database meer informatie.
Hardware-generaties in het aankoopmodel op basis van DTU
In het aankoopmodel op basis van DTU kunnen klanten niet kiezen welke hardwaregeneratie wordt gebruikt voor hun databases. Hoewel een bepaalde database meestal lange tijd op een specifieke hardwaregeneratie blijft (meestal voor meerdere maanden), zijn er bepaalde gebeurtenissen die ertoe kunnen leiden dat een database wordt verplaatst naar een andere hardwaregeneratie.
Een database kan bijvoorbeeld worden verplaatst naar een andere hardwaregeneratie 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 wordt verplaatst naar andere hardware, kunnen de prestaties van de werkbelasting veranderen. Het DTU-model garandeert dat de doorvoer- en reactietijd van de DTU-benchmarkworkload aanzienlijk identiek blijven als de database wordt verplaatst naar een andere hardwaregeneratie, zolang de servicedoelstelling (het aantal DTU's) hetzelfde blijft.
In het brede spectrum van workloads van klanten die in Azure SQL Database worden uitgevoerd, kan de impact van het gebruik van verschillende hardware voor dezelfde servicedoelstelling echter duidelijker zijn. Verschillende workloads 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 de ene hardwaregeneratie naar de andere wordt verplaatst.
Een toepassing die gevoelig is voor netwerklatentie kan bijvoorbeeld betere prestaties zien op Gen5-hardware dan Gen4 vanwege het gebruik van versneld netwerken in Gen5, maar een toepassing die intensief lees-I/O gebruikt, kan betere prestaties zien op Gen4-hardware dan Gen5 vanwege een hogere geheugen-per-kernverhouding in Gen4.
Klanten met workloads die gevoelig zijn voor hardwarewijzigingen of klanten die de keuze van hardwaregeneratie voor hun database willen bepalen, kunnen het vCore-model gebruiken om de gewenste hardwaregeneratie te kiezen tijdens het maken en schalen van de database. In het vCore-model worden resourcelimieten van elke servicedoelstelling voor elke hardwaregeneratie gedocumenteerd, voor zowel individuele databases als elastische pools. Zie Hardware-generaties voor SQL Database of Hardware-generaties voor SQL Managed Instance voor meer informatie over hardware-generaties in het vCore-model.
Veelgestelde vragen
Moet ik mijn toepassing offline halen om te converteren van een DTU-servicelaag naar een op vCore gebaseerde servicelaag?
Nee. U hoeft de toepassing niet offline te halen. De nieuwe servicelagen bieden een eenvoudige onlineconversiemethode die vergelijkbaar is met het bestaande proces van het upgraden van databases van de standard naar de Premium-servicelaag en andersom. U kunt deze conversie starten met behulp van de Azure Portal, PowerShell, de Azure CLI, T-SQL of de REST API. Zie voor meer informatie Individuele databases beheren en Elastische pools beheren.
Kan ik een database van een servicelaag in het aankoopmodel op basis van vCore converteren naar een servicelaag in het aankoopmodel op basis van DTU?
Ja, u kunt uw database eenvoudig converteren naar een ondersteunde prestatiedoelstelling met behulp van de Azure Portal, PowerShell, de Azure CLI, T-SQL of de REST API. Zie voor meer informatie Individuele databases beheren en Elastische pools beheren.