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
Sviluppare applicazioni serverless con Azure Container Apps
Minimal API con .NET
Ottimizzare il codice JavaScript con i Shorthand Patterns - seconda parte
Associare Application Insights ad una Web App tramite Azure ARM
Produrre un inventario automatico di Azure Storage
Utilizzare le Promise in Javascript - prima parte
Introduzione a Azure Container Apps
Usare domini personalizzati con Azure Container App
Continuous Deployment tramite GitOps
Comprimere le immagini contenute in un repository con una GitHub Action
YARP: un reverse proxy in ASP.NET Core
Utilizzare .NET 6 con le Azure Function
I più letti di oggi
- 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!
- YARP: un reverse proxy in ASP.NET Core
- Whidbey, Yukon e Longhorn su MSDN