Il database SQL di Azure ha attualmente tre livelli di servizio tra cui scegliere per il carico di lavoro. Questi livelli sono costituiti da Basic, Standard e Premium. Basic supporta solo una dimensione di 5 DTU. Premium parte da 125 DTU e arriva fino a 4.000 DTU. Il livello Premium è il livello superiore, creato per carichi di lavoro di I/O più elevati e offre una latenza inferiore per I/O e un ordine di grandezza in più di IOPS per DTU rispetto al livello Standard.
Prima di agosto 2017, il livello Standard supportava solo dimensioni DTU comprese tra 15 e 100 DTU. Attualmente sono disponibili in anteprima nuovi livelli di prestazioni e componenti aggiuntivi di archiviazione che offrono vantaggi di ottimizzazione dei prezzi per carichi di lavoro ad alta intensità di CPU. Con quelli, il livello Standard ora supporta fino a 3.000 DTU.
A questo punto, ti starai chiedendo cos'è esattamente un DTU? Una DTU è un'unità di transazione del database ed è una combinazione di CPU, memoria e I/O del registro delle transazioni e dei dati. (Andy Mallon, @AMtwo, ha recentemente affrontato questo problema in "Che diavolo è una DTU?") Puoi raggiungere il tuo limite DTU massimizzando CPU, memoria o I/O.
In precedenza, il livello Standard offriva solo 4 livelli:15, 30, 50 e 100 DTU, con un limite di dimensione del database di 250 GB, con disco standard. Se avevi un database più grande di 250 GB, ma non necessitavano di più di 100 DTU per CPU, memoria o I/O, eri bloccato a pagare un prezzo Premium solo per le dimensioni del database. Con le nuove modifiche, ora puoi avere fino a 1 TB di database nel livello Standard; devi solo pagare lo spazio di archiviazione extra. Attualmente lo spazio di archiviazione viene fatturato a $ 0,085/GB durante l'anteprima. Passando dalla dimensione inclusa di 250 GB a 1 TB, aumenta di 774 GB al costo di $ 65,79 al mese.
Le nuove dimensioni DTU di anteprima standard supportano le opzioni 200, 400, 800, 1.600 e 3.000 DTU. Se si dispone di un carico di lavoro del database di SQL Server che è più vincolato alla CPU rispetto all'I/O, queste opzioni del livello Standard possono potenzialmente farti risparmiare un sacco di soldi; tuttavia, se il carico di lavoro è legato all'I/O, il livello Premium supererà il livello Standard.
Ho deciso di provare due diversi carichi di lavoro per vedere quanto sono diversi i livelli Standard e Premium tra loro. Volevo creare test semplici e riproducibili in modo che gli altri potessero provare a convalidare se stessi. Per il mio primo test, volevo generare un sano mix di CPU e I/O. Speravo di spingere più CPU di I/O e di essere in grado di dimostrare che il livello Standard espanso avrebbe superato un livello Premium con la stessa dimensione DTU. Non ho ottenuto esattamente i risultati che speravo.
Per impostare questa demo, ho creato una tabella con tre colonne GUID, inserito 1 milione di righe e quindi aggiornato due delle tre colonne con nuovi ID. Il codice di esempio è di seguito:
CREATE TABLE dbo.TestTable ( Table_id UNIQUEIDENTIFIER DEFAULT NEWID(), Customer_id UNIQUEIDENTIFIER DEFAULT NEWID(), Cust_Name VARCHAR(40) DEFAULT CAST(NEWID() AS VARCHAR(40)) ); SET NOCOUNT ON; GO INSERT INTO dbo.TestTable DEFAULT VALUES; GO 1000000 CREATE CLUSTERED INDEX [ClustTestTable] ON [dbo].[TestTable] ( [Table_id] ASC, [Customer_id] ASC ); SET STATISTICS TIME ON; UPDATE TestTable SET Table_id = NEWID(), Customer_id = NEWID();
Mentre eseguivo la serie di test, le prestazioni sono costantemente migliorate nel livello Standard fino a quando non sono arrivato all'opzione S12 dove, stranamente, la CPU e il tempo trascorso sono aumentati. Ho eseguito il test più volte e S12 è stato costantemente di 54 secondi. È abbastanza chiaro con il mio primo test che il livello Premium ha superato il livello Standard. Ad esempio, S9 e P2 sono più vicini nel tempo, tuttavia la dimensione DTU per Standard è 1.600 rispetto a 250 per P2. Questo test riguarda maggiormente le capacità di I/O. Il grafico seguente mostra le dimensioni, il livello DTU, il costo, il tempo della CPU, il tempo trascorso e il tempo in secondi per ogni test:
Durante l'esecuzione dei test, ho osservato nella dashboard del monitor che l'I/O dati e la percentuale di I/O del registro erano la forza trainante della percentuale DTU. Il grafico seguente proveniva da un'esecuzione su un database S4:
Ho quindi deciso di provare un'altra serie di test che sarebbero stati più pesanti per la CPU. Per quel test ho usato il seguente script:
SET STATISTICS TIME ON;
SELECT SUM(CONVERT(BIGINT, t1.object_id)
+ CONVERT(BIGINT, t2.object_id)
+ CONVERT(BIGINT, t3.object_id)
+ CONVERT(BIGINT, t4.object_id))
FROM sys.objects t1
CROSS JOIN sys.objects t2
CROSS JOIN sys.objects t3
CROSS JOIN sys.objects t4; Quello che ho osservato nella dashboard del monitor in questa serie di test è che la percentuale della CPU era l'unico driver della percentuale DTU. Mentre eseguivo la serie di test nel livello Standard, il test sembrava stabilizzarsi a circa 27 secondi e iniziava con la dimensione S4. Ciò che mi ha colpito come strano è che un S4 a 200 DTU ha impiegato 27 secondi per essere completato e il corrispondente P2 a 250 DTU ha impiegato 38 secondi; un P4 a 500 DTU era più paragonabile. Se osserviamo il differenziale di costo per questa demo, un S4 durante l'anteprima costa solo $ 150,01, mentre un P4 costa $ 1.860; l'S4 offre un risparmio sui costi di poco più di $ 1.700. Immaginiamo che un P2 a 250 DTU si sia comportato come ci aspettavamo; un P2 costa $ 930 e costerebbe comunque $ 780 in più rispetto a un S4.
I risultati completi di tutti i test della seconda demo sono inclusi nel grafico seguente:
A differenza della prima demo, questa era guidata al 100% dalla CPU. Avevo provato a includere un cross join aggiuntivo, ma la demo ha richiesto ore per sessione anziché minuti. Per un test futuro cercherò di inventare alcuni scenari aggiuntivi che spingono un carico di lavoro OLTP più realistico; uno che ha una CPU più alta e uno che è più legato all'I/O, e quindi una discreta combinazione dei due.
Puoi vedere dal grafico sottostante che, in questa corsa su un database S4, la CPU ha raggiunto un picco di quasi il 50%, mentre la percentuale di DTU corrispondeva esattamente:
Dai due diversi carichi di lavoro che ho testato, è molto evidente che se hai un carico di lavoro di I/O significativo, avrai bisogno del livello Premium, ma se il tuo carico di lavoro è principalmente legato alla CPU senza necessità di I/O significative, maggiore è I livelli Standard possono offrirti risparmi sostanziali rispetto al livello Premium.
Se stai considerando una migrazione a un database SQL di Azure, il calcolatore DTU è un ottimo punto di partenza per avere un'idea di un punto di partenza per il dimensionamento; tuttavia, al momento della scrittura, il calcolatore DTU non prende in considerazione il livello Standard espanso. La cosa fantastica del calcolatore DTU è che romperà CPU, IOP e utilizzo dei registri per farti sapere qual è il fattore trainante per la raccomandazione del livello DTU. Ad esempio, ho eseguito l'ultima demo su una macchina virtuale da 4 vCPU, 4 GB e il calcolatore DTU ha consigliato un P2. Quando ho scelto di "visualizzare più dettagli", ho ricevuto i seguenti messaggi.
Livello di servizio/Livello di prestazioni per CPU – Basato esclusivamente sull'utilizzo della CPU, ti consigliamo di migrare il carico di lavoro di SQL Server a Premium – P2. Questo livello di servizio/livello di prestazioni dovrebbe coprire circa il 100,00% dell'utilizzo della CPU.
Livello di servizio/Livello di prestazioni per Iops – Basato esclusivamente sull'utilizzo di Iops, ti consigliamo di migrare il carico di lavoro di SQL Server a Basic. Questo livello di servizio/livello di prestazione dovrebbe coprire circa l'89,92% dell'utilizzo degli Iops.
NOTA:circa il 10,08% del tuo carico di lavoro rientra in un livello di servizio/livello di prestazioni superiore. Dopo aver migrato il database ad Azure, dovresti valutare le prestazioni del tuo database utilizzando le linee guida menzionate nella sezione delle informazioni sopra.
Livello di servizio/Livello di prestazioni per il registro – Basato esclusivamente sull'utilizzo dei log, ti consigliamo di migrare il carico di lavoro di SQL Server a Basic. Questo livello di servizio/livello di prestazioni dovrebbe coprire circa il 100,00% dell'utilizzo del registro.
Poiché so che questo carico di lavoro è fortemente vincolato alla CPU, se non riesco a ottimizzare il carico di lavoro per ridurre i requisiti di CPU, ho fino a 3.000 DTU disponibili nel livello Standard. Piuttosto che spendere $ 930 al mese per un P2 con 250 DTU, un S4 con 200 DTU a $ 150 al mese (o un S6 con 400 DTU a $ 300,02 al mese) sarebbe un'opzione molto più economica.
In conclusione, sono disponibili strumenti che consentono di determinare un buon punto di partenza per le dimensioni delle migrazioni del database SQL di Azure, tuttavia il metodo migliore in assoluto è testare il carico di lavoro. La migrazione di una copia del database di produzione, l'acquisizione di un carico di lavoro di produzione e la riproduzione di tale carico di lavoro sul database SQL di Azure ti consentirà di comprendere molto meglio le dimensioni della DTU di cui hai veramente bisogno.
