Microsoft Azure leverer Platform as a Service (PaaS) Database Engine gennem Azure SQL Database platformen, så vi kan bruge denne database til de cloud-baserede applikationer. Den største fordel ved Azure SQL-databasen er, at den muliggør nem skalering uden nedetid og kræver ingen versionsopgradering eller patchproces. Vi behøver heller ikke bekymre os om hardwareproblemer.

Den væsentlige overvejelse af Azure SQL-databasen er dog at opfylde ydeevnekravet for den installerede database mod minimumsomkostningerne. Der er utvivlsomt ingen, der ønsker at betale penge for de overflødige ressourcer eller funktioner, som de ikke bruger eller planlægger at bruge.

På dette tidspunkt tilbyder Microsoft Azure to forskellige indkøbsmodeller for at give omkostningseffektivitet:

• Database Transaction Unit (DTU)-baseret indkøbsmodel.
• Virtual Core (vCore)-baseret købsmodel

En købsmodelbeslutning påvirker direkte databasens ydeevne og det samlede beløb for regningerne. Efter min mening, hvis den installerede database ikke vil forbruge for mange ressourcer, vil den DTU-baserede indkøbsmodel være mere egnet.

Nu vil vi diskutere detaljerne om disse to indkøbsmodeller i de følgende afsnit.

Database Transaction Unit (DTU)-baseret indkøbsmodel

For at forstå den DTU-baserede indkøbsmodel mere klart, er vi nødt til at afklare, hvad der giver mening DTU i Azure SQL Database. DTU er en forkortelse for "Database Transaction Unit", og den beskriver en performance unit metric for Azure SQL Database. Vi kan ligesom DTU'en til hestekræfterne i en bil, fordi det direkte påvirker databasens ydeevne. DTU repræsenterer en blanding af følgende ydeevnemålinger som en enkelt ydeevneenhed for Azure SQL Database:

• CPU
• Hukommelse
• Data I/O og Log I/O

Hovedideen med DTU-konceptet er at tilbyde en prækonfigureret ressourcekonfiguration til klienter, så det forenkler skaleringen af ​​ydeevnen over en enkelt metrik. Såsom, hvis vi har brug for mere ydeevne, kan vi skubbe bjælken og øge antallet af DTU i Azure SQL Database.

DTU-baseret indkøbsmodel indeholder tre forskellige serviceniveauer, og disse serviceniveauer tilbyder forskellige DTU'er og funktionsmuligheder. Følgende tabel illustrerer de serviceniveauer, der har deltaget i den DTU-baserede indkøbsmodel.

Som vi kan se, varierer de maksimale DTU'er og funktioner afhængigt af deres serviceniveau. Prismodellen vil også blive ændret i forhold til serviceniveauet. For eksempel vil følgende konfiguration for en enkelt database i den DTU-baserede købsmodel være $584,00 pr. måned.

Elastisk pool

Kort fortalt hjælper Elastic Pool os med automatisk at administrere og skalere de mange databaser, der har uforudsigelige og varierende ressourcekrav til en delt ressourcepulje. Gennem Elastic Pool behøver vi ikke at skalere databaserne løbende mod udsving i ressourcebehov. De databaser, der deltager i puljen, bruger Elastic Pool-ressourcerne, når de er nødvendige, men de kan ikke overskride Elastic Pool-ressourcebegrænsningerne, så det giver en omkostningseffektiv løsning.

Korrekt estimering af DTU'en til Azure SQL-database

Efter at have besluttet at bruge DTU-baseret indkøbsmodel, skal vi finde ud af følgende spørgsmål-svar med logiske grunde:

• Hvilket serviceniveau og hvor mange DTU'er kræves for min arbejdsbyrde ved migrering til Azure SQL?

DTU Calculator vil være hovedløsningen til at estimere DTU's krav, når vi migrerer lokale databaser til Azure SQL Database. Hovedidéen med dette værktøj er at indfange de forskellige metrikudnyttelse fra den eksisterende SQL Server, der påvirker DTU'erne, og derefter forsøger det at estimere ca. DTU'er og serviceniveau i lyset af de indsamlede ydeevneudnyttelser. DTU-beregneren indsamler følgende metrics gennem enten Command-Line Utility eller PowerShell Script og gemmer disse metrics i en CSV-fil.

• Processor - % processortid
• Logisk disk - Disk læser/sek.
• Logisk disk - Diskskrivning/sek.
• Database - Log Bytes tømmes/sek.

I denne artikel lærer vi brugen af ​​Command-Line Utility, fordi dette er et open source-projekt og koder hostes på GitHub. Således kan vi nemt foretage ændringer, hvis vi har brug for det. Efter download og udpakning af kommandolinjeværktøjet, to filer vil komme foran os.

SqlDtuPerfmon.exe.config hjælper os med at bestemme nogle parametre for kommandolinjeværktøjet:

CsvPath angiver CSV-filstien, hvor de indsamlede metrics vil blive gemt.

SampleInterval angiver, hvor mange sekunders intervaller prøverne vil blive indsamlet

MaxSamples angiver det maksimale antal prøver, der vil blive indsamlet.

På dette tidspunkt er vi nødt til at tage nogle overvejelser om DTU Lommeregneren. DTU Lommeregner opsamler den samlede udnyttelse af metrikken på computeren. Af denne grund skal de andre processer, som påvirker CPU-, hukommelses- og diskforbruget, stoppes, ellers vil det være vanskeligt at foretage en nøjagtig DTU-estimering. Et andet problem er, som muligt, at vi er nødt til at indsamle brugen af ​​de metrics, der dækker spidsbelastningstidsintervaller. På denne måde giver DTU Lommeregneren de bedste anbefalinger, og vi finder ud af det maksimale DTUs krav med et mere omtrentligt skøn. Nu vil vi køre SqlDtuPerfmon.exe, og det vil direkte begynde at indsamle ressourceudnyttelse og gemme den angivne CSV-fil.

Efter færdiggørelsen af ​​indsamlingen af ​​ressourceudnyttelsen, indtaster vi antallet af kernerne og uploader CSV-filen til DTU Calculator's hjemmeside.

Når vi klikker på knappen Beregn, vises for det første et cirkeldiagram over serviceniveau/ydelsesniveau på skærmen, og det viser de opdelte estimerede forslag til serviceniveauer i skiver med procentdetaljerne. Ifølge DTU Calculator vil Standard - S6 tier give en tilfredsstillende ydeevne for denne arbejdsbyrde.

Lige under dette diagram vises DTUs Over Time-diagram, og dette diagram repræsenterer DTU'erne, der ændrer sig i forhold til tidsperioden. Før vi evaluerer dette diagram, kan vi tilføje nogle yderligere oplysninger for at fortolke det lettere.

Som du kan se, repræsenterer linjediagrammet en ustabil arbejdsbyrde, men det gav mere mening, da vi tilføjede informationsnoter. Efter min mening er dette diagram meget nyttigt til at forstå samspillet mellem ændringer i arbejdsbelastning og DTU'er. Således kan vi lave en mere korrekt vurdering af de nødvendige DTU'er. Som vi nævnte ved indgangen til artiklen, bør vores hovedmål være at finde en omkostningseffektiv løsning til arbejdsbyrden.

Disse forslag udtrykker dog ikke de præcise krav til DTU'en i Azure SQL. Af denne grund kan vi være nødt til at ændre Service Tier eller Purchase Model efter implementeringen af ​​databasen til Azure SQL.

Når vi klikker på Vis flere detaljer, vil nogle yderligere rapporter blive vist, og disse rapporter repræsenterer de individuelle anbefalinger for CPU-, IOPS- og logressourceudnyttelse. De vil være meget nyttige til at forstå især disse anvendelser.

Virtuel kerne (vCore)-baseret indkøbsmodel

Dette koncept ligner den traditionelle tilgang, fordi vi er i stand til at bestemme hver enkelt ressource i databasen. Vi kan arrangere VCores og maks. datastørrelsesmuligheder manuelt i denne model. Vi kan dog ikke bestemme hukommelsesressourcen. Hver VCore leveres med dedikeret hukommelse, og den dedikerede værdi af hukommelsen afhænger af genereringen af ​​VCores.

Til sidst kan vi i denne model vælge følgende serviceniveauer:

• Generelt formål.
• Forretningskritisk.
• Hyperskala

Konklusion

I denne artikel undersøgte vi indkøbsmodellerne for Azure SQL-databasen, og vi afslører brugsinstruktionerne for DTU-beregneren for at estimere den nødvendige DTU i Azure SQL til on-premise databaser.