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
Creare una libreria CSS universale - Rotazione degli elementi
Creare gruppi di client per Event Grid MQTT
Sfruttare al massimo i topic space di Event Grid MQTT
Utilizzare Tailwind CSS all'interno di React: primi componenti
Autenticarsi in modo sicuro su Azure tramite GitHub Actions
Utilizzare gRPC su App Service di Azure
Gestione dell'annidamento delle regole dei layer in CSS
Ottimizzare le performance delle collection con le classi FrozenSet e FrozenDictionary
Migrare una service connection a workload identity federation in Azure DevOps
Ordinare randomicamente una lista in C#
Disabilitare automaticamente un workflow di GitHub
.NET Conference Italia 2024