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
Cambiare la chiave di partizionamento di Azure Cosmos DB
Sfruttare lo stream rendering per le pagine statiche di Blazor 8
Gestire la cancellazione di una richiesta in streaming da Blazor
Utilizzare QuickGrid di Blazor con Entity Framework
Migliorare la sicurezza dei prompt con Azure AI Studio
Migrare una service connection a workload identity federation in Azure DevOps
Utilizzare Azure AI Studio per testare i modelli AI
Sfruttare MQTT in cloud e in edge con Azure Event Grid
Utilizzare politiche di resiliency con Azure Container App
Utilizzare Model as a Service su Microsoft Azure
Potenziare Azure AI Search con la ricerca vettoriale
Ordinare randomicamente una lista in C#