Il database SQL di Azure è l'offerta database-as-a-service di Microsoft che offre un'enorme flessibilità. È costruito come parte dell'ambiente Platform-as-a-Service che fornisce ai clienti monitoraggio e sicurezza aggiuntivi per il prodotto.
Microsoft lavora continuamente per migliorare i propri prodotti e il database SQL di Azure non fa eccezione. Molte delle funzionalità più recenti di SQL Server sono state inizialmente avviate nel database SQL di Azure, inclusi (ma non limitati a) Always Encrypted, Dynamic Data Masking, sicurezza a livello di riga e Query Store.
Livello tariffario DTU
Quando il database SQL di Azure è stato lanciato per la prima volta, esisteva un'unica opzione di prezzo nota come "DTU" o unità di transazione del database. (Andy Mallon, @AMtwo, spiega le DTU in "Che diavolo è una DTU?") Il modello DTU offre tre livelli di servizio, base, standard e premium. Il livello base fornisce fino a 5 DTU con archiviazione standard. Il livello standard supporta da 10 a 3000 DTU con storage standard, mentre il livello premium supporta da 125 a 4000 DTU con storage premium, un numero di ordini di grandezza più veloce rispetto allo storage standard.
Piano tariffario vCore
Alcuni anni dopo il rilascio del database SQL di Azure, quando Istanza gestita SQL di Azure era in anteprima pubblica e sono stati annunciati i "vCore" (core virtuali) per il database SQL di Azure. Questi hanno introdotto i livelli per uso generico e business-critical con processori Gen 4 e Gen 5. La quinta generazione è ora l'opzione hardware principale per la maggior parte delle regioni poiché la quarta generazione sta per scadere.
Gen 5 supporta un minimo di 2 vCore e fino a 80 vCore con ram allocata a 5,1 GB per vCore. Il livello per uso generico fornisce archiviazione remota con IOPS dati massimi che vanno da 640 per un database 2 vCore fino a 25.600 per un database 80 vCore. Il livello business-critical ha SSD locale che fornisce prestazioni IO molto migliori con IOPS dati massimi che vanno da 8000 per un database 2 vCore fino a 204.800 per un database 80 vCore. Sia i livelli per uso generico che quelli business-critical raggiungono un massimo di 4.096 GB per l'archiviazione e questo è diventato un limite per molti clienti.
Database HyperScale
Per risolvere il limite di 4 TB del database SQL di Azure, Microsoft ha creato il livello iperscalabile. L'iperscalabilità consente ai clienti di scalare fino a 100 TB di dimensioni del database, oltre a fornire una scalabilità orizzontale rapida per i nodi di sola lettura. Puoi anche scalare facilmente su e giù all'interno del modello vCore. I database con iperscalabilità vengono forniti tramite vCore. Con la Gen 5, un database Hyperscale può utilizzare da 2 a 80 vCore e da 500 a 204.800 IOPS. L'iperscalabilità consente di ottenere prestazioni elevate da ciascun nodo di elaborazione dotato di cache basate su SSD che aiutano a ridurre al minimo i round trip di rete per recuperare i dati. C'è molta tecnologia fantastica coinvolta con Hyperscale nel modo in cui è progettato per utilizzare cache e server di pagine basati su SSD. Ti consiglio vivamente di dare un'occhiata al diagramma che scompone l'architettura e come funziona in questo articolo.
Database senza server
Un'altra richiesta molto comune da parte dei clienti era la possibilità di aumentare e ridurre automaticamente il proprio database SQL di Azure man mano che i carichi di lavoro aumentano e diminuiscono. I clienti hanno tradizionalmente la possibilità di aumentare e diminuire a livello di codice usando PowerShell, Automazione di Azure e altri metodi. Microsoft ha preso l'idea e ha creato un nuovo livello di calcolo chiamato database SQL di Azure serverless, che è diventato generalmente disponibile a novembre 2019. Consentono al cliente di impostare il numero minimo e massimo di vCore. In questo modo possono sapere che è sempre disponibile un livello di calcolo minimo e possono sempre scalare automaticamente a un livello di calcolo designato. C'è anche la possibilità di configurare un ritardo di pausa automatica. Questa impostazione consente di sospendere automaticamente il database dopo un determinato periodo di inattività del database. Quando un database entra nella fase di pausa automatica, i costi di calcolo vanno a zero e vengono sostenuti solo i costi di archiviazione. Il costo complessivo di serverless è la somma del costo di calcolo e del costo di archiviazione. Quando l'utilizzo del calcolo è compreso tra i limiti minimo e massimo, il costo del calcolo si basa sui vCore e sulla memoria utilizzata. Se l'utilizzo effettivo è inferiore al valore minimo, il costo di calcolo si basa sui vCore minimi e sulla memoria minima configurati.
Il livello serverless ha il potenziale per far risparmiare ai clienti una grande quantità di denaro, dando loro anche la possibilità di fornire un'esperienza utente del database coerente con il database in grado di scalare in base alla domanda.
Piscine elastiche
Il database SQL di Azure dispone di un modello di risorse condivise che consente ai clienti di avere un maggiore utilizzo delle risorse. Un cliente può creare un pool elastico e spostare i database in quel pool. Ciascun database può quindi iniziare a condividere risorse predefinite all'interno di quel pool. I pool elastici possono essere configurati utilizzando il modello tariffario DTU o il modello vCore. I clienti determinano la quantità di risorse di cui il pool elastico ha bisogno per gestire il carico di lavoro per tutti i suoi database. I limiti delle risorse possono essere configurati per database in modo che un database non possa consumare l'intero pool. I pool elastici sono ideali per i clienti che devono gestire un numero elevato di database o scenari multi-tenant.
Nuova configurazione hardware per il livello di calcolo con provisioning
Le configurazioni hardware Gen4/Gen5 sono considerate "memoria e calcolo bilanciati". Funziona bene per molti carichi di lavoro di SQL Server, tuttavia, ci sono stati casi d'uso per una latenza della CPU inferiore e una velocità di clock più elevata per carichi di lavoro pesanti per la CPU e la necessità di maggiore memoria per vCore. Microsoft ha fornito e creato ancora una volta una configurazione hardware ottimizzata per il calcolo e la memoria. Questi sono attualmente in anteprima e disponibili solo in alcune regioni.
Nel livello con provisioning per uso generico puoi selezionare la serie Fsv2 che può offrire prestazioni CPU maggiori per vCore rispetto all'hardware Gen 5. Nel complesso, la dimensione di 72 vCore può fornire prestazioni della CPU maggiori rispetto a 80 vCore Gen 5 fornendo una latenza della CPU inferiore e velocità di clock più elevate. La serie Fsv2 ha meno memoria e tempdb per vCore rispetto a Gen 5, quindi questo dovrà essere preso in considerazione.
Nel livello di provisioning business-critical, puoi accedere alla serie M che è ottimizzata per la memoria. La serie M offre 29 GB per vCore rispetto ai 5,1 GB per vCore nella configurazione "bilancia memoria e calcolo". Con la serie M puoi scalare vCore fino a 128, fornendo fino a 3,7 TB di memoria. Per abilitare la serie M, devi essere attualmente in un contratto Pay-As-You-Go o Enterprise e aprire una richiesta di supporto. Anche in questo caso, la serie M è attualmente disponibile solo negli Stati Uniti orientali, nell'Europa settentrionale, nell'Europa occidentale, negli Stati Uniti occidentali 2 e potrebbe anche avere una disponibilità limitata in altre regioni.
Conclusione
Il database SQL di Azure è una piattaforma di database ricca di funzionalità che offre un'ampia gamma di opzioni per il calcolo e la scalabilità. I clienti possono configurare il calcolo per un singolo database o pool elastico utilizzando DTU o vCore. Per i database con requisiti di archiviazione elevati o scalabilità orizzontale in lettura, è possibile utilizzare Hyperscale. Per i clienti con requisiti di carico di lavoro variabili, il serverless può essere utilizzato per aumentare e ridurre automaticamente le esigenze del carico di lavoro. Una novità del database SQL di Azure è la funzionalità di anteprima di una configurazione hardware ottimizzata per il calcolo e per la memoria per i clienti che necessitano di CPU a latenza inferiore o con requisiti elevati da memoria a CPU.
Per ulteriori informazioni sulle risorse di Azure, consulta i miei articoli precedenti:
- Opzioni di ottimizzazione delle prestazioni del database SQL di Azure
- Considerazioni sulle prestazioni delle istanze gestite SQL di Azure
- Nuove dimensioni del livello standard del database SQL di Azure
- Colmare il divario di Azure:istanze gestite
- Migrazione dei database al database SQL di Azure
