Dimensionare per scala e prestazioni

Modelli di acquisto: DTU e vCore

Azure SQL Database si acquista in due modi. Il modello DTU impacchetta CPU, memoria e IO in un’unica unità astratta: si sceglie un livello (Basic, Standard, Premium) e si accetta il mix deciso da Microsoft. È semplice ma opaco — non si capisce quale risorsa sia il collo di bottiglia e non si può aumentare l’archiviazione senza salire anche di calcolo. Il modello vCore espone le risorse separatamente: numero di vCore, generazione hardware, storage configurato a parte. È quindi la risposta corretta ogni volta che il requisito parla di dimensionare calcolo e archiviazione in modo indipendente, di attribuire il costo per componente o di riusare licenze SQL Server con Software Assurance tramite Azure Hybrid Benefit. Da ricordare: Azure SQL Managed Instance esiste solo nel modello vCore, e tutte le opzioni moderne (Hyperscale, serverless) vivono lì.

I service tier

General Purpose separa calcolo e archiviazione: i file del database risiedono su remote storage e, in caso di guasto, viene ricreato il nodo di calcolo e i file vengono riagganciati. È il compromesso standard per la maggior parte dei carichi di lavoro. Business Critical usa storage locale SSD e un insieme di repliche nella stessa regione basato sulla tecnologia Always On: latenza di IO più bassa, resilienza intra-region più alta e una read-only replica utilizzabile impostando ApplicationIntent=ReadOnly nella stringa di connessione. Hyperscale è un’architettura diversa: log service, page server e nodi di calcolo disaggregati. Va scelto quando il database è molto grande o cresce in modo imprevedibile, quando servono backup e restore rapidi quasi indipendenti dalla dimensione dei dati, e quando si vogliono aggiungere repliche o cambiare taglia di calcolo in tempi brevi. Hyperscale risponde alla scala, non alla latenza dello storage locale.

Serverless, provisioned ed elastic pool

Il calcolo provisioned riserva una capacità fissa e la fattura sempre. Il calcolo serverless scala automaticamente entro un intervallo di vCore minimo e massimo, fattura il calcolo effettivamente consumato e può andare in auto-pause dopo un periodo di inattività configurabile: durante la pausa si paga solo l’archiviazione. È la scelta giusta per database intermittenti, ambienti di sviluppo e test, carichi imprevedibili in cui il sovradimensionamento costa più della latenza. Il prezzo da pagare è il ritardo di resume alla prima connessione dopo una pausa, inaccettabile per un’applicazione sempre attiva; per un carico continuo e prevedibile il provisioned costa meno.

L’elastic pool risolve un problema diverso: molti database, ciascuno con picchi brevi e non sovrapposti nel tempo. Invece di dimensionare ogni database per il proprio picco, si compra un budget condiviso (eDTU o vCore) e si lasciano i database attingervi, fissando eventualmente minimi e massimi per database perché uno solo non affami gli altri. Se i picchi sono simultanei, il pool non aiuta: serve capacità dedicata.

Table partitioning e data compression

Il table partitioning distribuisce una tabella secondo una partition function e un partition scheme. Il beneficio principale è la manutenzione: lo sliding window con SWITCH PARTITION permette di caricare o eliminare un intero periodo come operazione di metadati, al posto di un DELETE massivo che gonfia il transaction log, e consente di ricostruire indici o comprimere una singola partizione. Il partition elimination in query si ottiene solo se il predicato filtra sulla partitioning column.

La data compression ha due livelli: ROW ottimizza la memorizzazione dei tipi a lunghezza fissa, PAGE aggiunge prefix e dictionary compression a livello di pagina. Meno pagine significa meno IO e più dati utili nel buffer pool, al costo di CPU aggiuntiva. Criterio pratico: ROW dove la CPU è già sotto pressione o la scrittura è intensa, PAGE su tabelle grandi lette in scansione; sp_estimate_data_compression_savings serve a stimare prima di decidere.

Trappole tipiche d’esame

• Scalare archiviazione e calcolo separatamente, o applicare Azure Hybrid Benefit → modello vCore: il DTU li lega insieme e non consente il riuso delle licenze; se lo scenario cita entrambi i modelli, il vincolo di indipendenza è il discriminante.
• Database molto grande con restore rapido → Hyperscale, non Business Critical: Business Critical ottimizza latenza e repliche locali, non la dimensione né la velocità delle operazioni di scala.
• Replica leggibile senza costi aggiuntivi → Business Critical (o una named replica in Hyperscale), non General Purpose: su General Purpose il carico di lettura va indirizzato altrove.
• Molti database con picchi non sovrapposti → elastic pool; picchi simultanei → capacità dedicata: l’elastic pool condivide risorse, non le moltiplica.
• Database usato poche ore al giorno → serverless con auto-pause; applicazione always-on → provisioned: il ritardo di resume è il motivo per cui il serverless viene scartato negli scenari a disponibilità continua.
• Purga periodica dello storico che satura il log → partition switching, non DELETE: e la compressione non è la risposta a un problema di logging, riduce IO ma consuma CPU.