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
Utilizzare gRPC su App Service di Azure
Creare una libreria CSS universale: i bottoni
Creare una custom property in GitHub
Migrare una service connection a workload identity federation in Azure DevOps
Utilizzare un service principal per accedere a Azure Container Registry
Implementare l'infinite scroll con QuickGrid in Blazor Server
Autenticarsi in modo sicuro su Azure tramite GitHub Actions
Migliorare l'organizzazione delle risorse con Azure Policy
Visualizzare le change sul plan di Terraform tramite le GitHub Actions
Generare velocemente pagine CRUD in Blazor con QuickGrid
Sostituire la GitHub Action di login su private registry
Utilizzare Azure AI Studio per testare i modelli AI
I più letti di oggi
- Recuperare automaticamente un utente e aggiungerlo ad un gruppo di Azure DevOps
- Supportare la sessione affinity di Azure App Service con Application Gateway
- Gli oggetti CallOut di Expression Blend 4.0
- Conoscere il rendering Server o WebAssembly a runtime in Blazor
- Utilizzare un DataContext specifico per la modalità design time di Blend e Visual Studio nei controlli Silverlight
- Più sezioni di configurazione attraverso il nodo <configSections /> del web.config