Introduzione a Database di Azure per PostgreSQL
Database di Azure per PostgreSQL è disponibile nelle versioni multiserver.
In qualità di sviluppatore di database, con esperienza pluriennale nell'esecuzione e nella gestione delle installazioni di PostgreSQL locali, si vuole esaminare il modo in cui Database di Azure per PostgreSQL è in grado supportare e ridimensionare le funzionalità di queste installazioni.
In questa unità si esploreranno le opzioni relative ai prezzi, al supporto delle versioni, alla replica e alla scalabilità di Database di Azure per PostgreSQL.
Database di Azure per PostgreSQL
Il servizio Database di Azure per PostgreSQL è un'implementazione della versione community di PostgreSQL. Il servizio fornisce le funzionalità comuni usate dai classici sistemi PostgreSQL, tra cui il supporto geospaziale e la ricerca full-text.
Microsoft ha adattato PostgreSQL per la piattaforma Azure, consentendo una stretta integrazione con molti servizi di Azure. Il servizio Database di Azure per PostgreSQL è completamente gestito da Microsoft. Microsoft gestisce gli aggiornamenti e le patch per il software e offre una disponibilità del 99,99% garantita da contratto di servizio. In questo modo, gli sviluppatori possono dedicarsi interamente ai database e alle applicazioni in esecuzione, sfruttando al tempo stesso il servizio.
In ogni istanza del servizio possono essere distribuiti più database.
Piani tariffari
Quando si crea un'istanza del servizio Database di Azure per PostgreSQL, si specificano le risorse di calcolo e di archiviazione da allocare selezionando un piano tariffario. Un piano tariffario è basato sul numero di core di processore virtuale, sulla quantità di spazio di archiviazione disponibile e su varie opzioni di backup. Il costo è direttamente proporzionale alla quantità di risorse allocate.
Il servizio Database di Azure per PostgreSQL usa le risorse di archiviazione per memorizzare i file di database, i file temporanei, i log delle transazioni e i log del server. È anche possibile specificare che si vuole aumentare la capacità di archiviazione disponibile quando si sta per raggiungere il limite di capacità. Se non si seleziona questa opzione, i server in cui si esauriscono le risorse di archiviazione continueranno a funzionare, ma in modalità di sola lettura.
I piani tariffari dei gruppi del portale di Azure sono suddivisi in tre ampi intervalli:
- Basic, adatto a sistemi e ambienti di sviluppo di piccole dimensioni, ma con prestazioni di I/O variabili.
- Utilizzo generico, che offre prestazioni prevedibili, fino a 6000 IOPS, a seconda del numero di core del processore e dello spazio di archiviazione disponibile.
- Con ottimizzazione per la memoria, che usa fino a 32 core di processore virtuale ottimizzati per la memoria e offre prestazioni prevedibili fino a 6000 IOPS.
Microsoft offre anche un'opzione di archiviazione su larga scala, disponibile in anteprima, che consente il provisioning di un massimo di 16 TB di spazio di archiviazione e il supporto di un massimo di 20.000 IOPS.
È possibile ottimizzare il numero di core del processore e l'archiviazione necessaria. È possibile aumentare e ridurre le risorse di elaborazione (ma non ridurre le risorse di archiviazione, solo aumentarle) e passare dal piano tariffario Utilizzo generico a quello Con ottimizzazione per la memoria o viceversa, in base alle esigenze, dopo aver creato i database. Si paga solo per le risorse usate.
Nota
Se si modifica il numero di core del processore, Azure crea un nuovo server con la specifica allocazione di risorse di calcolo. Quando il nuovo server è in esecuzione, le connessioni client vengono trasferite al nuovo server. Questo processo può richiedere al massimo un minuto. Durante questo intervallo non è possibile stabilire nuove connessioni e verrà eseguito il rollback delle transazioni in corso.
Se si modificano solo le dimensioni di archiviazione delle opzioni di backup, il servizio non viene interrotto.
Il piano tariffario e le risorse di elaborazione allocate determinano il numero massimo di connessioni simultanee supportate dal servizio. Se, ad esempio, si seleziona il piano tariffario Utilizzo generico e si allocano 64 core virtuali, il servizio supporta 1900 connessioni simultanee. Il livello Basic, con due core virtuali, gestisce fino a 100 connessioni simultanee. Cinque di queste connessioni sono necessarie ad Azure per monitorare il server. Se si supera il numero di connessioni disponibili, i client riceveranno un errore irreversibile in cui viene segnalato che ci sono già troppi client.
I prezzi possono variare. Per informazioni aggiornate, visitare la pagina dei prezzi di Database di Azure per PostgreSQL.
Parametri del server
In un'installazione locale di PostgreSQL è possibile impostare i parametri di configurazione del server nel file postgresql.conf. Usare Database di Azure per PostgreSQL per modificare i parametri di configurazione tramite la pagina Parametri del server. Non tutti i parametri relativi a un'installazione locale di PostgreSQL sono pertinenti per Database di Azure per PostgreSQL. Pertanto, nella pagina Parametri del server sono elencati solo i parametri appropriati per Azure.
Le modifiche apportate ai parametri contrassegnati come Dinamici diventano immediatamente effettive. Per i parametri statici è necessario riavviare il server. Per riavviare il server si usa il pulsante Riavvia nella pagina Panoramica del portale:
Disponibilità elevata
Database di Azure per PostgreSQL è un servizio a disponibilità elevata. Contiene meccanismi di rilevamento degli errori e failover predefiniti. Se un nodo di elaborazione si blocca a causa di un problema hardware o software, viene attivato in sostituzione un nuovo nodo. Tutte le connessioni che attualmente usano quel nodo verranno rimosse, ma aperte automaticamente sul nuovo nodo. Per tutte le transazioni eseguite dal nodo in errore verrà eseguito il rollback. È quindi sempre necessario assicurarsi che i client siano configurati in modo da rilevare e ripetere le operazioni non riuscite.
Versioni di PostgreSQL supportate
Il servizio Database di Azure per PostgreSQL supporta attualmente PostgreSQL versione 11 e precedenti, fino alla versione 9.5. Si specifica la versione di PostgreSQL da usare quando si crea un'istanza del servizio. Microsoft intende aggiornare il servizio man mano che le nuove versioni di PostgreSQL diventano disponibili, mantenendo comunque la compatibilità con le due versioni principali precedenti.
Azure gestisce automaticamente gli aggiornamenti ai database tra le versioni secondarie di PostgreSQL, ma non tra le versioni principali. Se, ad esempio, si ha un database che usa PostgreSQL versione 10, Azure può aggiornare automaticamente il database alla versione 10.1. Se si vuole passare alla versione 11, è necessario esportare i dati dai database nell'istanza del servizio corrente, creare una nuova istanza del servizio Database di Azure per PostgreSQL e importare i dati in questa nuova istanza.
Nodi coordinatore e di lavoro
I dati vengono partizionati e distribuiti tra i nodi di lavoro. Il motore di query del coordinatore può parallelizzare query complesse, indirizzando l'elaborazione verso i nodi di lavoro appropriati. I nodi di lavoro vengono selezionati in base alle partizioni di database che contengono i dati in fase di elaborazione. Il coordinatore accumula quindi i risultati dai nodi di lavoro prima di inviarli di nuovo al client. È possibile eseguire query più semplici usando un solo nodo di lavoro. I client si connettono al coordinatore e non comunicano mai direttamente con un nodo di lavoro.
È possibile ridimensionare il numero di nodi di lavoro nel servizio, in base alle esigenze.
Distribuzione dei dati
È possibile distribuire i dati tra i nodi di lavoro creando tabelle distribuite. Una tabella distribuita viene suddivisa in partizioni di database e ogni partizione viene allocata alle risorse di archiviazione in un nodo di lavoro. Si indica come suddividere i dati definendo una colonna come colonna di distribuzione. I dati vengono partizionati in base ai valori dei dati in questa colonna. Quando si progetta una tabella distribuita, è importante selezionare attentamente la colonna di distribuzione. È consigliabile usare una colonna con un numero elevato di valori distinti che normalmente verrebbero usati per raggruppare le righe correlate. Ad esempio, in una tabella per un sistema di e-commerce che archivia le informazioni sugli ordini dei clienti, l'ID cliente potrebbe essere una colonna di distribuzione adeguata. Tutti gli ordini di un determinato cliente verranno conservati nella stessa partizione, ma gli ordini di tutti i clienti verranno distribuiti tra le partizioni.
È inoltre possibile creare tabelle di riferimento, ovvero tabelle che contengono dati di ricerca, come nomi di città o codici di stato. Una tabella di riferimento viene replicata interamente in ogni nodo di lavoro. I dati di una tabella di riferimento devono essere relativamente statici. Ogni modifica richiede l'aggiornamento di ogni copia della tabella.
È infine possibile creare tabelle locali. Una tabella locale non è partizionata, ma è archiviata nel nodo coordinatore. Le tabelle di questo tipo vengono usate per contenere tabelle di piccole dimensioni con dati che in genere non sono necessari per i join, ad esempio i nomi degli utenti e i relativi dettagli di accesso.
Eseguire la replica dei dati in Database di Azure per PostgreSQL
Le repliche di sola lettura sono utili per la gestione di carichi di lavoro che richiedono numerose operazioni di lettura. Le connessioni client possono essere distribuite tra le repliche, in modo da alleggerire il carico su una singola istanza del servizio. Se i client si trovano in aree geografiche diverse del mondo, si usa la replica tra aree per posizionare i dati vicino a ogni set di client e ridurre così la latenza.
È inoltre possibile usare le repliche nell'ambito di un piano di emergenza per il ripristino di emergenza. Se il server master non risulta più disponibile, si ha comunque la possibilità connettersi a una replica.
Nota
Se il database master viene perso o eliminato, tutte le repliche di sola lettura diventano server di lettura/scrittura. Questi server saranno tuttavia indipendenti l'uno dall'altro e quindi le modifiche apportate ai dati in un server non verranno copiate nei server rimanenti.
Creazione di una replica
Una replica di sola lettura contiene una copia dei database contenuti nel server originale, definito master. Per creare una replica di un server master è possibile usare il portale di Azure o l'interfaccia della riga di comando.
Quando si crea una replica di sola lettura, Azure crea una nuova istanza del servizio Database di Azure per PostgreSQL e quindi copia i database dal server master al nuovo server. La replica viene eseguita in modalità di sola lettura. Qualsiasi tentativo di modificare i dati avrà esito negativo.
Ritardo della replica
Il processo di replica non è sincrono e tutte le modifiche apportate ai dati nel server master possono richiedere del tempo per essere visualizzate nelle repliche. Le applicazioni client che si connettono alle repliche devono essere in grado di far fronte a questo livello di coerenza finale. Con Monitoraggio di Azure è possibile tenere traccia dell'intervallo di tempo necessario per completare il processo di replica usando le metriche relative al ritardo massimo tra le repliche e al ritardo di replica.
Gestione e monitoraggio
Per connettersi a Database di Azure per PostgreSQL al fine di gestire e monitorare i database è possibile usare strumenti con cui si ha familiarità, come pgAdmin. Tuttavia, alcune funzionalità incentrate sul server, ad esempio l'esecuzione del backup e del ripristino del server, non sono disponibili perché il server è gestito da Microsoft.
Strumenti di Azure per il monitoraggio di Database di Azure per PostgreSQL
Azure offre un set completo di servizi che consentono di monitorare le prestazioni del server e del database e di risolvere eventuali problemi. Questi servizi consentono di visualizzare il modo in cui PostgreSQL utilizza le risorse di Azure allocate. Queste informazioni sono utili per valutare se è necessario ridimensionare il sistema, modificare la struttura delle tabelle e degli indici nei database, nonché visualizzare le statistiche di runtime e altri eventi. I servizi disponibili includono:
Monitoraggio di Azure. Database di Azure per PostgreSQL fornisce le metriche che consentono di tenere traccia di dati quali l'utilizzo della CPU e delle risorse di archiviazione, le velocità di I/O, l'utilizzo della memoria, il numero di connessioni attive e il ritardo di replica:
Log del server. In Azure sonno disponibili i log relativi a ogni server PostgreSQL. È possibile scaricarli dal portale di Azure:
Query Data Store e Informazioni dettagliate prestazioni query. Il servizio Database di Azure per PostgreSQL registra le informazioni sulle query eseguite sui database nel server e le salva in un database denominato azure_sys, nello schema query_store. Per visualizzare queste informazioni, si esegue una query sulla vista query_store.qs_view. Per impostazione predefinita, Database di Azure per PostgreSQL non acquisisce informazioni sulle query perché impone un sovraccarico limitato, ma è possibile abilitare il rilevamento impostando la proprietà del server pg_qs.query_capture_mode su ALL o TOP.
È anche possibile configurare Query Data Store per acquisire informazioni sulle query che richiedono un tempo di attesa. Una query può dover rimanere in attesa perché un'altra query deve rilasciare un blocco su una tabella, perché la query esegue un numero elevato di operazioni di I/O o perché la memoria è insufficiente. Queste informazioni sono riportate nella vista query_store.runtime_stats_view.
Se si preferisce visualizzare queste statistiche anziché eseguire istruzioni SQL, usare Informazioni dettagliate prestazioni query nel portale di Azure:
Raccomandazioni per le prestazioni. L'utilità Raccomandazioni per le prestazioni, disponibile anche nel portale di Azure, esamina le query in esecuzione nelle applicazioni. Controlla inoltre le strutture nel database, offre raccomandazioni su come organizzare i dati e indica se è necessario valutare l'aggiunta o la rimozione di indici.
Connettività client
Database di Azure per PostgreSQL viene eseguito all'interno di un firewall. Per accedere al servizio e al database, è necessario aggiungere una regola del firewall per gli intervalli di indirizzi IP da cui i client si connettono. Se si deve accedere al servizio direttamente da Azure, ad esempio da un'applicazione eseguita con Servizio app di Azure, è necessario abilitare anche l'accesso ai servizi di Azure.
Configurare il firewall
Il modo più semplice per configurare il firewall consiste nell'usare le impostazioni Sicurezza connessione per il servizio nel portale di Azure. Aggiungere una regola per ogni intervallo di indirizzi IP dei client. Questa pagina viene usata anche per applicare le connessioni SSL al servizio.
Per aggiungere l'indirizzo IP del computer desktop, fare clic su Aggiungi IP client sulla barra degli strumenti.
Se si sono configurate repliche di sola lettura, è necessario aggiungere una regola del firewall a ciascuna di esse per renderle accessibili ai client.
Librerie di connessione client
Se si scrivono applicazioni client personalizzate, è necessario usare il driver di database appropriato per connettersi a un database PostgreSQL. Molte di queste librerie sono dipendenti dal linguaggio di programmazione e sono gestite da terze parti indipendenti. Database di Azure per PostgreSQL supporta le librerie client per Python, PHP, Node.js, Java, Ruby, Go, C# (.NET), ODBC, C e C++.
Logica di ripetizione dei tentativi client
Come indicato in precedenza, alcuni eventi, quali il failover durante il ripristino a disponibilità elevata e l'aumento delle risorse della CPU, possono causare una breve perdita di connettività. Per tutte le transazioni in corso verrà eseguito il rollback. Database di Azure per PostgreSQL reindirizza automaticamente un client connesso a un nodo di lavoro, ma tutte le operazioni eseguite dal client in quel momento restituiranno un errore. È consigliabile considerare questa occorrenza come un'eccezione temporanea. Il codice dell'applicazione deve essere preparato in modo da intercettare queste eccezioni e riprovare.
Funzionalità di PostgreSQL supportate in Database di Azure per PostgreSQL
Database di Azure per PostgreSQL supporta la maggior parte delle funzionalità usate comunemente dai database PostgreSQL, ma esistono alcune eccezioni. Se è necessaria una funzionalità non supportata, si dovrà rielaborare il codice dell'applicazione e del database per rimuovere questa dipendenza oppure provare a eseguire PostgreSQL in una macchina virtuale. In quest'ultimo caso, sarà necessario assumersi la responsabilità della gestione del server.
Estensioni supportate in Database di Azure per PostgreSQL
Molte funzionalità di PostgreSQL sono incapsulate nelle estensioni. Le estensioni sono pacchetti di oggetti e codice SQL archiviati nel server, che possono essere caricati in un database tramite il comando CREATE EXTENSION. Database di Azure per PostgreSQL offre attualmente molte estensioni di uso comune per:
- Tipo di dati
- Funzioni
- Ricerca full-text
- Indici (bloom, btree_gist e btree_gin)
- Linguaggio plpgsql
- PostGIS
- Molte funzioni amministrative
I pacchetti dblink e postgres_fdw vengono usati per connettere un server PostgreSQL a un altro, in modo da consentire al codice di un server di accedere ai dati contenuti in un altro server. In Database di Azure per PostgreSQL è possibile connettersi solo tra server creati con Database di Azure per PostgreSQL. Non è possibile creare connessioni in uscita a server PostgreSQL ospitati altrove, ad esempio in locale o in una macchina virtuale.
Nota
L'elenco delle estensioni supportate è costantemente sottoposto a revisione e può cambiare. Per generare un elenco delle estensioni supportate viene usata la query seguente. Si noti che non è possibile creare estensioni personalizzate e caricarle in Database di Azure per PostgreSQL:
SELECT * FROM pg_available_extensions;
Database di Azure per PostgreSQL include il database TimescaleDB come estensione facoltativa. Questo database contiene funzioni analitiche orientate al tempo e altre funzionalità che supportano i carichi di lavoro basati su serie temporali. Per usare questo database, selezionare l'opzione TIMESCALEDB nel parametro del server shared_preload_libraries e quindi riavviare il server.
Supporto di linguaggi per stored procedure e trigger
Per il supporto di linguaggi diversi da plpgsql è in genere necessario compilare separatamente il codice di stored procedure o trigger e caricare la libreria compilata nel server. Non è possibile eseguire questa operazione con Database di Azure per PostgreSQL. Questa limitazione è dovuta principalmente a motivi di sicurezza. Se si ha codice scritto in altri linguaggi, sarà necessario eseguirne il porting a plpgsql.