Azure SQL Database è il servizio della piattaforma Azure che ci permette di avere un SQL Server sul cloud completamente gestito. E' uno dei primi servizi che sono stati messi a disposizione e dispone di due modelli di acquisto: tramite DTU o tramite vCore. Il primo ci permette di specificare un indicatore che va regolare il numero massimo di tempo CPU, RAM e I/O che il nostro database (o pool di database) ha a disposizione. Nel secondo modello scegliamo in modo indipendente il numero di vCore allocati e separatamente paghiamo lo spazio occupato dal nostro database. Quest'ultimo dà più trasparenza e ci garantisce le prestazioni che vogliamo, anche se più costoso.
Di recente è stata introdotta una nuova variante a questo modello di nome Serverless che si affianca a quella Provisioned. In questa configurazione quello che scegliamo sono il numero minimo e massimo di vCore che vogliamo sfruttare e proporzionalmente la RAM che abbiamo a disposizione. Dal pannello di configurazione troviamo infatti la nuova selezione e i due slider.

Lo scaling è quindi automatico e adattivo secondo le esigenze di query e connessioni contemporanee, e grazie a piani di esecuzione è in grado di applicare le risorse necessarie a mantenere ottime le prestazioni.
Il billing è applicato per secondo ed è adatto per gli scenari in cui è difficile prevedere l'utilizzo del database perché ad intermittenza o sottoposto a picchi di utilizzo, situazioni nella quale prima dell'introduzione di questa feature eravamo costretti a fare variazioni dei DTU tramite script, anche se con forti limitazioni.
Per ottimizzare ancor di più i costi, possiamo attivare anche l'auto pause, cioè non allocare nessun vCore annullando quindi la componente CPU dal billing. Sempre nella stessa pagina possiamo abilitare questa funzione e decidere dopo quanto tempo di inattività mettere in pausa i core.

Per inattività intendiamo sessioni uguali a zero (concetto diverso dalle connessioni e dal pool di esse) e carico di CPU a zero. Purtroppo, il periodo minimo di pausa dev'essere di 6 ore, perciò non è detto che possa essere adatto a quei software sfruttati di più di giorno rispetto alla notte. Nella figura seguente possiamo vedere un grafico che ci fa capire l'uso dei core e cosa vuol dire mettere in pausa il database.

Credits: docs.microsoft.com
Sebbene in questo frangente di tempo non paghiamo la CPU, resta comunque presente il costo dello storage occupato.
Mettere in pausa significa inoltre dover riattivare i core quando necessario, cioè quando svolgiamo qualsiasi attività sul database. Questa operazione richiede anche un minuto e causa dei primi rifiuti di connessione perciò dobbiamo dal punto di vista applicativo gestire questa situazione. Insomma, per quanto possa sembrare un'ottima feature è necessario prestare molta attenzione al suo utilizzo.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Migliorare la scalabilità delle Azure Function con il Flex Consumption
Ordine e importanza per @layer in CSS
Modificare i metadati nell'head dell'HTML di una Blazor Web App
Utilizzare DeepSeek R1 con Azure AI
Creare una libreria CSS universale - Rotazione degli elementi
Generare una User Delegation SAS in .NET per Azure Blob Storage
Filtrare i dati di una QuickGrid in Blazor con una drop down list
Creare gruppi di client per Event Grid MQTT
Gestire gli accessi con Token su Azure Container Registry
Gestire i dati con Azure Cosmos DB Data Explorer
Come EF 8 ha ottimizzato le query che usano il metodo Contains
Creare un webhook in Azure DevOps