PostgreSQL è un DBMS molto diffuso presente sul mercato da moltissimi anni che offre elevate prestazioni e gode di caratteristiche particolari, come l'ereditarietà dei tipi e il supporto a JSON e a XML. Sebbene sia nato in ambito on-premises, quando ancora il cloud non esisteva, è normale potersi aspettare questo database anche nell'ambito cloud.
Microsoft Azure fornisce una soluzione completamente managed di PostegreSQL che offre tutti i vantaggi del cloud: in pochi click abbiamo un server con la gestione trasparente dello storage, dei backup, del networking e della sicurezza.
Come per ogni servizio Azure possiamo creare un server direttamente dal portale e allocarlo nella region di nostro interesse. Esistono tre tipologie, ma in questo script ci occuperemo del singolo server, che permette di disporre fino a 64 virtual core e 16TB di dati, perciò più che sufficienti per gli utilizzi più comuni. Possiamo scegliere versioni differenti del database, dalla 9.5 alla 11, e specificare il numero di vcore da utilizzare partendo da un minimo di 1.

Ogni server include gratuitamente, per la stessa quantità di storage preallocato, il backup del database stesso, effettuato con una frequenza di 5 minuti per il transaction log, backup differenziali 2 volte al giorno e un backup settimanalie. Possiamo decidere di conseguenza per quanto tenere i backup, per un minimo di 7 giorni.
Creato il server è opportuno accedere alla sezione Connection security poiché l'accesso non è consentito ad alcun IP, nemmeno ai servizi Azure. Possiamo quindi abilitare quest'ultimi o indicare range di IP. Importante, inoltre, mantenere abilitato il TLS per crittografare le comunicazioni.

Nella sezione Connection strings possiamo invece vedere le stringhe di connessioni da adottare a seconda del driver di comunicazione. Da notare che l'utente da utilizzare è nella forma utente@nomeServer mentre SSL va abilitato in maniera esplicita.
Come normalmente previsto per i database gestititi, nella sezione Pricing tier possiamo cambiare autonomamente la capacità computazionale e lo spazio allocato.

Godiamo inoltre di una sezione dedicata alle prestazioni che ci permette di identificare le query più impegnative e di ricevere raccomandazioni per eventuali ottimizzazioni, più un sistema di replica di dati verso server geo distribuiti con accesso in lettura.
Va considerato infine, che il costo è determinato principalmente dalla componente core, più lo spazio allocato e lo spazio occupato dai backup.
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
Ridurre il reflow cambiando il CSS
Documentare i servizi REST con Swagger e OpenAPI con .NET 9
Anonimizzare i dati sensibili nei log di Azure Front Door
Creare agenti facilmente con Azure AI Agent Service
Ridurre il reflow ottimizzando il CSS
Utilizzare EF.Constant per evitare la parametrizzazione di query SQL
Testare il failover sulle region in Azure Storage
Supportare la sessione affinity di Azure App Service con Application Gateway
Centralizzare gli endpoint AI Foundry con Azure API Management
Inference di dati strutturati da testo con Semantic Kernel e ASP.NET Core Web API
Managed deployment strategy in Azure DevOps
I più letti di oggi
- Gestione ciclo di vita in .NET Aspire
- Sfruttare i nuovi overload di TimeSpan.From* per creare timespan usando numeri interi
- .NET Conference Italia 2024 - Milano
- Gestione CSS in Blazor con .NET 9
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!