Microsoft Azure levert Platform as a Service (PaaS) Database Engine via het Azure SQL Database platform, zodat we deze database kunnen gebruiken voor de cloud-based applicaties. Het belangrijkste voordeel van de Azure SQL Database is dat het eenvoudig kan worden geschaald zonder downtime en dat er geen versie-upgrades of patchproces nodig zijn. We hoeven ons ook geen zorgen te maken over hardwareproblemen.

De belangrijkste overweging van de Azure SQL Database is echter om te voldoen aan de prestatievereiste van de geïmplementeerde database tegen minimale kosten. Niemand wil ongetwijfeld geld betalen voor de overtollige bronnen of functies die ze niet gebruiken of van plan zijn te gebruiken.

Op dit moment biedt Microsoft Azure twee verschillende inkoopmodellen om kostenefficiëntie te bieden:

• Gebaseerd aankoopmodel op databasetransactie-eenheid (DTU).
• Virtual Core (vCore)-gebaseerd aankoopmodel

Een beslissing over een aankoopmodel heeft rechtstreeks invloed op de prestaties van de database en het totaalbedrag van de rekeningen. Naar mijn mening, als de geïmplementeerde database niet te veel bronnen verbruikt, zal het op DTU gebaseerde aankoopmodel geschikter zijn.

Nu zullen we de details over deze twee aankoopmodellen in de volgende secties bespreken.

Op database Transaction Unit (DTU) gebaseerd aankoopmodel

Om het DTU-gebaseerde aankoopmodel beter te begrijpen, moeten we verduidelijken wat een zinvolle DTU is in Azure SQL Database. DTU is een afkorting voor de "Database Transaction Unit" en beschrijft een prestatie-eenheidsmetriek voor de Azure SQL Database. We kunnen de DTU net zo leuk vinden als de pk's in een auto, omdat het rechtstreeks van invloed is op de prestaties van de database. DTU vertegenwoordigt een combinatie van de volgende prestatiestatistieken als een enkele prestatie-eenheid voor Azure SQL Database:

• CPU
• Geheugen
• Data I/O en Log I/O

Het belangrijkste idee van het DTU-concept is om een ​​vooraf geconfigureerde resourceconfiguratie aan te bieden aan clients, zodat het schalen van de prestaties over een enkele metriek wordt vereenvoudigd. Als we bijvoorbeeld meer prestaties nodig hebben, kunnen we de balk verschuiven en het aantal DTU in Azure SQL Database verhogen.

Het op DTU gebaseerde aankoopmodel bevat drie verschillende servicelagen en deze servicelagen bieden verschillende DTU's en functie-opties. De volgende tabel illustreert de serviceniveaus die hebben deelgenomen aan het op DTU gebaseerde aankoopmodel.

Zoals we kunnen zien, variëren de maximale DTU's en functies afhankelijk van hun serviceniveau. Ook zal het prijsmodel worden gewijzigd in verband met de servicelaag. De volgende configuratie voor een enkele database in het DTU-gebaseerde aankoopmodel is bijvoorbeeld $ 584,00 per maand.

Elastisch zwembad

Kort gezegd, Elastic Pool helpt ons om automatisch de meerdere databases te beheren en te schalen die onvoorspelbare en variërende resourcevereisten hebben voor een gedeelde resourcepool. Via de Elastic Pool hoeven we de databases niet continu te schalen tegen fluctuaties in de vraag naar resources. De databases die deelnemen aan de pool verbruiken de Elastic Pool-bronnen wanneer ze nodig zijn, maar ze kunnen de beperkingen van de Elastic Pool-bronnen niet overschrijden, zodat het een kosteneffectieve oplossing biedt.

Goede schatting van de DTU voor Azure SQL Database

Nadat we besloten hebben om een ​​op DTU gebaseerd aankoopmodel te gebruiken, moeten we het volgende vraag-antwoord met logische redenen achterhalen:

• Welke servicelaag en hoeveel DTU's zijn vereist voor mijn workload bij het migreren naar Azure SQL?

DTU Calculator is de belangrijkste oplossing om de vereiste DTU's te schatten wanneer we on-premises databases migreren naar Azure SQL Database. Het belangrijkste idee van deze tool is het vastleggen van het gebruik van verschillende metrieken van de bestaande SQL Server die van invloed zijn op de DTU's en vervolgens probeert het een schatting te maken van de DTU's en de servicelaag in het licht van het verzamelde prestatiegebruik. De DTU-rekenmachine verzamelt de volgende metrieken via het Command-Line Utility of PowerShell Script en slaat deze metrieken op in een CSV-bestand.

• Processor - % processortijd
• Logische schijf - Schijf leest/sec
• Logische schijf - Schijfschrijven/sec
• Database - Logbytes gewist/sec

In dit artikel zullen we het gebruik van het Command-Line-hulpprogramma leren, omdat dit een open-sourceproject is en codes worden gehost op de GitHub. Zo kunnen we gemakkelijk wijzigingen aanbrengen als dat nodig is. Na het downloaden en uitpakken van het opdrachtregelprogramma, twee bestanden zullen voor ons verschijnen.

SqlDtuPerfmon.exe.config helpt ons bij het bepalen van enkele parameters van het opdrachtregelhulpprogramma:

CsvPath specificeert het CSV-bestandspad waar de verzamelde metrieken worden opgeslagen.

SampleInterval specificeert hoeveel seconden intervallen de samples zullen worden verzameld

MaxSamples specificeert het maximum aantal samples dat zal worden verzameld.

Op dit punt moeten we rekening houden met enkele overwegingen over de DTU-calculator. DTU Calculator verzamelt het totale gebruik van de statistieken op de computer. Om deze reden moeten de andere processen die van invloed zijn op het CPU-, geheugen- en schijfverbruik worden gestopt, anders wordt het moeilijk om een ​​nauwkeurige schatting van de DTU's te maken. Een ander probleem is dat we, indien mogelijk, het gebruik moeten verzamelen van de metrische gegevens die de piekintervallen van de werkbelasting dekken. Op deze manier biedt de DTU-calculator de beste aanbevelingen en vinden we de maximale DTU-eis met een meer geschatte schatting. Nu zullen we SqlDtuPerfmon.exe uitvoeren en het zal direct beginnen met het verzamelen van resourcegebruik en het opslaan van het gespecificeerde CSV-bestand.

Nadat het verzamelen van het resourcegebruik is voltooid, voeren we het aantal kernen in en uploaden we het CSV-bestand naar de DTU Calculator-website.

Wanneer we op de knop Berekenen klikken, verschijnt eerst het cirkeldiagram Service Tier/Performance Level op het scherm en toont het de opgedeelde geschatte servicetier-suggesties in segmenten met de procentuele details. Volgens DTU Calculator levert de Standard - S6-laag bevredigende prestaties voor deze werkbelasting.

Net onder deze grafiek wordt de grafiek DTU's in de loop van de tijd weergegeven en deze grafiek geeft de DTU's weer die veranderen ten opzichte van de tijdsperiode. Voordat we dit diagram evalueren, kunnen we wat extra informatie toevoegen om het gemakkelijker te kunnen interpreteren.

Zoals u kunt zien, vertegenwoordigt het lijndiagram een ​​onstabiele werklast, maar het was logischer toen we informatienotities toevoegden. Naar mijn mening is deze grafiek erg handig om de interactie tussen werklastveranderingen en DTU's te begrijpen. Zo kunnen we een betere inschatting maken van de benodigde DTU's. Zoals we aan het begin van het artikel al zeiden, moet ons belangrijkste doel zijn om een ​​kosteneffectieve oplossing voor de werkdruk te vinden.

Deze suggesties geven echter niet de precieze vereisten van de DTU in Azure SQL weer. Om deze reden moeten we mogelijk de servicelaag of het aankoopmodel wijzigen na de implementatie van de database naar Azure SQL.

Wanneer we op Meer details weergeven klikken, worden enkele aanvullende rapporten weergegeven en deze rapporten vertegenwoordigen de individuele aanbevelingen voor het gebruik van CPU, IOPS en logboekbronnen. Ze zullen zeer nuttig zijn om met name deze toepassingen te begrijpen.

Virtual core (vCore)-gebaseerd inkoopmodel

Dit concept is vergelijkbaar met de traditionele aanpak omdat we in staat zijn om elke bron van de database te beslissen. We kunnen de VCores en maximale gegevensgrootte-opties handmatig in dit model rangschikken. We kunnen de geheugenbron echter niet bepalen. Elke VCore wordt geleverd met toegewezen geheugen en de toegewezen waarde van het geheugen hangt af van de generatie van de VCores.

Als laatste kunnen we in dit model de volgende serviceniveaus kiezen:

• Algemeen doel.
• Bedrijfskritiek.
• Hyperschaal

Conclusie

In dit artikel hebben we de aankoopmodellen van de Azure SQL Database onderzocht en hebben we de gebruiksinstructies van de DTU-calculator blootgelegd om de vereiste DTU in Azure SQL voor on-premise databases te schatten.