Microsoft Azure tillhandahåller Platform as a Service (PaaS) Databas Engine via Azure SQL Database-plattformen, så att vi kan använda denna databas för molnbaserade applikationer. Den främsta fördelen med Azure SQL Database är att den möjliggör enkel skalning med noll driftstopp och kräver ingen versionsuppgradering eller korrigeringsprocess. Dessutom behöver vi inte oroa oss för maskinvaruproblem.

Det viktiga övervägandet med Azure SQL-databasen är dock att uppfylla prestandakraven för den distribuerade databasen mot lägsta kostnad. Utan tvekan vill ingen betala pengar för de redundanta resurserna eller funktionerna som de inte använder eller planerar att använda.

För närvarande erbjuder Microsoft Azure två olika inköpsmodeller för att ge kostnadseffektivitet:

• Databas Transaction Unit (DTU)-baserad inköpsmodell.
• Virtual Core (vCore)-baserad inköpsmodell

Ett inköpsmodellbeslut påverkar direkt databasens prestanda och det totala beloppet på räkningarna. Enligt min tanke, om den distribuerade databasen inte kommer att förbruka för många resurser kommer den DTU-baserade inköpsmodellen att vara mer lämplig.

Nu kommer vi att diskutera detaljerna om dessa två inköpsmodeller i följande avsnitt.

Databas Transaction Unit (DTU)-baserad inköpsmodell

För att förstå den DTU-baserade inköpsmodellen tydligare måste vi klargöra vad som är meningsfullt DTU i Azure SQL Database. DTU är en förkortning för "Databas Transaction Unit" och beskriver ett prestandaenhetsmått för Azure SQL Database. Vi kan precis som DTU:n till hästkrafterna i en bil eftersom det direkt påverkar databasens prestanda. DTU representerar en blandning av följande prestandamått som en enda prestandaenhet för Azure SQL Database:

• CPU
• Minne
• Data I/O och Log I/O

Huvudidén med DTU-konceptet är att erbjuda en förkonfigurerad resurskonfiguration till klienter så att den förenklar skalningen av prestandan över ett enda mått. Till exempel, om vi behöver mer prestanda, kan vi skjuta ribban och öka antalet DTU i Azure SQL Database.

DTU-baserad inköpsmodell innehåller tre olika servicenivåer och dessa servicenivåer erbjuder olika DTU:er och funktionsalternativ. Följande tabell illustrerar de tjänstenivåer som har deltagit i den DTU-baserade köpmodellen.

Som vi kan se varierar de maximala DTU:erna och funktionerna beroende på deras servicenivå. Prismodellen kommer också att ändras relaterat till tjänstenivån. Till exempel kommer följande konfiguration för en enskild databas i den DTU-baserade inköpsmodellen att vara 584,00 USD per månad.

Elastisk pool

Kortfattat, Elastic Pool hjälper oss att automatiskt hantera och skala de flera databaser som har oförutsägbara och varierande resurskrav på en delad resurspool. Genom Elastic Pool behöver vi inte skala databaserna kontinuerligt mot fluktuationer i resursefterfrågan. Databaserna som deltar i poolen förbrukar Elastic Pool-resurserna när de behövs men de kan inte överskrida Elastic Pool-resursbegränsningarna så att det ger en kostnadseffektiv lösning.

Korrekt uppskattning av DTU:n för Azure SQL Database

Efter att ha beslutat att använda DTU-baserad inköpsmodell måste vi ta reda på följande frågesvar med logiska skäl:

• Vilken tjänstnivå och hur många DTU:er krävs för min arbetsbelastning vid migrering till Azure SQL?

DTU Calculator kommer att vara huvudlösningen för att uppskatta DTU-kravet när vi migrerar lokala databaser till Azure SQL Database. Huvudidén med det här verktyget är att fånga upp de olika måttenheterna från den befintliga SQL-servern som påverkar DTU:erna och sedan försöker den uppskatta ungefär DTU:er och tjänstenivå i ljuset av de insamlade prestandaanvändningarna. DTU-kalkylatorn samlar in följande mätvärden genom antingen kommandoradsverktyget eller PowerShell-skriptet och sparar dessa mätvärden i en CSV-fil.

• Processor - % processortid
• Logisk disk - Disk läser/sek
• Logisk disk - Diskskrivning/sek
• Databas - Loggbytes tömda/sek

I den här artikeln kommer vi att lära oss användningen av kommandoradsverktyget eftersom detta är ett projekt med öppen källkod och koder finns på GitHub. Således kan vi enkelt göra ändringar om vi behöver. Efter nedladdning och uppackning av kommandoradsverktyget, två filer kommer framför oss.

SqlDtuPerfmon.exe.config hjälper oss att fastställa några parametrar för kommandoradsverktyget:

CsvPath anger CSV-filsökvägen där de insamlade mätvärdena kommer att lagras.

SampleInterval anger hur många sekunders intervall proverna kommer att samlas in

MaxSamples anger det maximala antalet prover som kommer att samlas in.

Vid det här laget måste vi ta hänsyn till några överväganden om DTU-kalkylatorn. DTU Calculator samlar in det totala utnyttjandet av måtten på datorn. Av denna anledning måste de andra processerna som påverkar CPU, minne och diskförbrukning stoppas, annars blir det svårt att göra en korrekt uppskattning av DTU:er. En annan fråga är att vi som möjligt måste samla in användningen av de mätvärden som täcker tidsintervaller för toppbelastningar. På detta sätt ger DTU-kalkylatorn de bästa rekommendationerna och vi tar reda på det maximala DTU-kravet med en mer ungefärlig uppskattning. Nu kommer vi att köra SqlDtuPerfmon.exe och den börjar direkt samla in resursutnyttjande och spara den angivna CSV-filen.

Efter att vi har samlat in resursutnyttjandet kommer vi att ange antalet kärnor och ladda upp CSV-filen till DTU Calculator-webbplatsen.

När vi klickar på knappen Beräkna visas först servicenivå/prestandanivå cirkeldiagram på skärmen och det visar de uppdelade uppskattade servicenivåförslagen i segment med procentdetaljer. Enligt DTU Calculator kommer Standard - S6-nivån att ge en tillfredsställande prestanda för denna arbetsbelastning.

Strax under detta diagram visas diagram över DTU:er över tid och detta diagram representerar DTU:erna som ändras mot tidsperioden. Innan vi utvärderar det här diagrammet kan vi lägga till ytterligare information för att lättare tolka det.

Som du kan se representerar linjediagrammet en instabil arbetsbelastning men det var mer meningsfullt när vi lade till informationsanteckningar. Enligt min uppfattning är det här diagrammet mycket användbart för att förstå interaktionen mellan förändringar i arbetsbelastningen och DTU:er. Således kan vi göra en mer korrekt uppskattning av de nödvändiga DTU:erna. Som vi nämnde i början av artikeln bör vårt huvudmål vara att hitta en kostnadseffektiv lösning för arbetsbördan.

Dessa förslag uttrycker dock inte de exakta kraven för DTU:n i Azure SQL. Av denna anledning kan vi behöva ändra Service Tier eller Purchase Model efter distributionen av databasen till Azure SQL.

När vi klickar på Visa fler detaljer kommer några ytterligare rapporter att visas och dessa rapporter representerar de individuella rekommendationerna för resursanvändning av CPU, IOPS och logg. De kommer att vara till stor hjälp för att förstå särskilt dessa användningsområden.

Virtuell kärna (vCore)-baserad inköpsmodell

Detta koncept liknar det traditionella tillvägagångssättet eftersom vi kan bestämma varje resurs i databasen. Vi kan ordna VCores och maxdatastorleksalternativ manuellt i denna modell. Vi kan dock inte fastställa minnesresursen. Varje VCore levereras med dedikerat minne och det dedikerade värdet på minnet beror på genereringen av VCores.

Till sist kan vi i denna modell välja följande tjänstenivåer:

• Allmänt syfte.
• Affärskritisk.
• Hyperskala

Slutsats

I den här artikeln utforskade vi inköpsmodellerna för Azure SQL-databasen och vi avslöjar användningsinstruktionerna för DTU-kalkylatorn för att uppskatta nödvändig DTU i Azure SQL för lokala databaser.