In più script abbiamo parlato di Azure Cosmos Db, strumento tra i più importanti servizi offerti dalla piattaforma Azure, perché in ottica PaaS ci fornisce un database documentale, e non solo, geo distribuito dalle altissime prestazioni.
Il throughput è la variabile fondamentale che ci troviamo a dovere dimensionare per poter decidere quanto carico di lavoro il database può supportare e di conseguenza la velocità e il numero di richieste concorrenti che riusciamo a soddisfare. Questo numero, espresso in RU/s, è in funzione della dimensione del documento che andiamo a leggere e a scrivere, e del tipo di operazione effettuate. Trovare un numero non è facile, perché esso costituisce un costo fisso e non possiamo quindi permetterci né di esagerare né di sottodimensionare le capacità.
Inoltre, ci sono scenari in cui il carico di lavoro non è prevedibile, oppure ancora dove gli applicativi hanno lunghi periodi di inattività, oppure dove effettuiamo dei grossi carichi di lavoro temporanei per poi mantenere inutilizzato il database. In queste situazioni l'autoscale, introdotto recentemente, è la soluzione più adatta. In pratica diamo un tetto massimo di RU/s che il database può raggiungere e istantaneamente il limite si adatta per soddisfare tutte le richieste che arrivano.
Possiamo abilitare l'autoscale su container o database già presenti oppure in fase di creazione degli stessi, e in qualsiasi momento tornare al sistema manuale. Se throughput è distribuito per l'intero database, anche l'autoscale può essere applicato a più container. Nell'immagine seguente si vede il flag da abilitare.
Il tetto massimo è fondamentale per tenere sotto controllo i costi. E' facile essere tentati, infatti, a mettere un max RU/s molto alto, ma bisogna considerare che basta un picco di richiesta per far sì che un'intera ora che venga contabilizzata con le RU/s che sono state necessarie per quel picco. Abbiamo quindi un adattamento e un costo piuttosto aderente con dei limiti che vanno tenuti in considerazione. Va inoltre considerato che le RU/s, in caso di mancato utilizzo del database, non scendono comunque sotto le 400 RU/s, andando a costituire il costo minimo mensile.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Sostituire la GitHub Action di login su private registry
Ottimizzare la latenza in Blazor 8 tramite InteractiveAuto render mode
Estrarre dati randomici da una lista di oggetti in C#
Persistere la ChatHistory di Semantic Kernel in ASP.NET Core Web API per GPT
C# 12: Cosa c'è di nuovo e interessante
Eseguire query manipolando le liste contenute in un oggetto mappato verso una colonna JSON
Generare la software bill of material (SBOM) in GitHub
Eseguire operazioni sui blob con Azure Storage Actions
Migliorare la scalabilità delle Azure Function con il Flex Consumption
Eseguire i worklow di GitHub su runner potenziati
Esportare ed analizzare le issue di GitHub con la CLI e GraphQL
Utilizzare politiche di resiliency con Azure Container App
I più letti di oggi
- Sfruttare le API di geolocalizzazione di JavaScript
- Webcast 'Windows Vista: WinFX il framework per gli sviluppatori'
- Impostare il tema light o dark utilizzando i CSS
- Proteggere le risorse Azure con private link e private endpoints
- Cambiare automaticamente lo stato di un work item in una pipeline di Azure DevOps
- Criptare la comunicazione con mTLS in Azure Container Apps
- Ottimizzare l'aggiornamento di una entity sul database con Entity Framework
- Usare entità non mappate come parametri in metodi Invoke di WCF Ria Services e Silverlight
- Annunciata la licenza commerciale di Kinect for Windows: dal primo febbraio 2012