Introduzione a Database di Azure per PostgreSQL

Completato

Database di Azure per PostgreSQL è disponibile nelle versioni multiserver.

Gli sviluppatori di database con molti anni di esperienza nell'esecuzione e nella gestione delle installazioni postgreSQL locali consentono di esplorare il supporto e la scalabilità delle funzionalità di Database di Azure per PostgreSQL.

In questa unità verranno esaminati i prezzi, il supporto delle versioni, la replica e le opzioni di ridimensionamento 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 sistemi PostgreSQL tipici, tra cui il supporto geografico e la ricerca full-text.

Microsoft ha adattato PostgreSQL per la piattaforma Azure ed è strettamente integrato 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 fornisce un contratto di servizio 99.99% disponibilità. Ciò significa che è possibile concentrarsi solo sui database e sulle applicazioni in esecuzione, usando il servizio .

È possibile distribuire più database in ogni istanza di questo servizio.

Livelli di prezzo

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 combina il numero di core del processore virtuale, la quantità di spazio di archiviazione disponibile e varie opzioni di backup. Più risorse allocare, maggiore è il costo.

Il servizio Database di Azure per PostgreSQL usa l'archiviazione per contenere i file di database, i file temporanei, i log delle transazioni e i log del server. Facoltativamente, è possibile specificare che lo spazio di archiviazione disponibile venga aumentato quando si avvicina alla capacità corrente. Se non si seleziona questa opzione, i server che esauriscono lo spazio di archiviazione continueranno a essere in esecuzione, ma funzionano come di sola lettura.

Il portale di Azure raggruppa i piani tariffari in tre intervalli generali:

  • basic, adatto per sistemi di piccole dimensioni e ambienti di sviluppo, ma presenta prestazioni di I/O variabili.
  • utilizzo generico, che offre prestazioni prevedibili, fino a 6000 operazioni di I/O al secondo, a seconda del numero di core del processore e dello spazio di archiviazione disponibile.
  • memoria ottimizzata, che usa fino a 32 core del processore virtuale ottimizzati per la memoria e offre prestazioni prevedibili fino a 6000 operazioni di I/O al secondo.

Microsoft offre anche un'opzione di archiviazione di grandi dimensioni in anteprima, che può effettuare il provisioning fino a 16 TB di archiviazione e supportare fino a 20.000 operazioni di I/O al secondo.

È possibile ottimizzare il numero di core del processore e l'archiviazione necessari. È possibile aumentare e ridurre le risorse di elaborazione, ovvero non è possibile ridurre le risorse di archiviazione, solo aumentare, e passare dai piani tariffari per utilizzo generico e ottimizzato per la memoria in base alle esigenze dopo aver creato i database. Si paga solo per ciò che serve.

Immagine che mostra i piani tariffari nel portale di Azure

Nota

Se si modifica il numero di core del processore, Azure crea un nuovo server con questa allocazione di calcolo. Quando il server è in esecuzione, le connessioni client vengono passate al nuovo server. Questa opzione può richiedere fino a un minuto. Durante questo intervallo non è possibile effettuare nuove connessioni e verrà eseguito il rollback delle transazioni in anteprima.

Se si modificano solo le dimensioni di archiviazione delle opzioni di backup, non si verifica alcuna interruzione nel servizio.

Il piano tariffario e le risorse di elaborazione allocate determinano il numero massimo di connessioni simultanee supportate dal servizio. Ad esempio, se si seleziona il piano tariffario Per 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. Azure richiede cinque di queste connessioni per monitorare il server. Se si supera il numero di connessioni disponibili, i client riceveranno l'errore FATAL: spiacenti, troppi client già.

I prezzi possono cambiare. Per informazioni più recenti, visitare la pagina prezzi di Database di Azure per PostgreSQL.

Parametri del server

In un'installazione locale di PostgreSQL i parametri di configurazione del server vengono impostati nel file postgresql.conf. Usare Database di Azure per PostgreSQL per modificare i parametri di configurazione tramite la pagina parametri di Server. Non tutti i parametri per un'installazione locale di PostgreSQL sono rilevanti per Database di Azure per PostgreSQL, quindi la pagina Parametri del server elenca solo i parametri appropriati per Azure.

Immagine che mostra la pagina Parametri del server nel portale di Azure

Le modifiche apportate ai parametri contrassegnati come dinamiche diventano effettive immediatamente. I parametri statici richiedono un riavvio del server. Riavviare il server usando il pulsante Riavvia nella pagina Panoramica nel portale:

Immagine che mostra la pagina Panoramica nel portale di Azure con il pulsante Riavvia evidenziato

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, verrà impostato un nuovo nodo per sostituirlo. Tutte le connessioni attualmente che usano tale nodo verranno eliminate ma aperte automaticamente sul nuovo nodo. Verrà eseguito il rollback di tutte le transazioni eseguite dal nodo con errori. Per questo motivo, è sempre necessario assicurarsi che i client siano configurati per rilevare e ripetere le operazioni con errori.

Versioni di PostgreSQL supportate

Il servizio Database di Azure per PostgreSQL supporta attualmente PostgreSQL versione 11, fino alla versione 9.5. Specificare la versione di PostgreSQL da usare quando si crea un'istanza del servizio. Microsoft intende aggiornare il servizio man mano che diventano disponibili nuove versioni di PostgreSQL e manterrà la compatibilità con le due versioni principali precedenti.

Azure gestisce automaticamente gli aggiornamenti ai database tra le versioni secondarie di PostgreSQL, ma non le versioni principali. Ad esempio, se si dispone di 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 nel coordinatore può parallelizzare query complesse, indirizzando l'elaborazione verso i nodi di lavoro appropriati. I nodi di lavoro vengono selezionati in base alle partizioni che contengono i dati elaborati. 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 anche al coordinatore e non comunicano mai direttamente con un nodo di lavoro.

È possibile aumentare e ridurre il numero di nodi di lavoro nel servizio in base alle esigenze.

Distribuzione dei dati

I dati vengono distribuiti tra nodi di lavoro creando tabelle distribuite. Una tabella distribuita viene suddivisa in partizioni e ogni partizione viene allocata all'archiviazione in un nodo di lavoro. Si indica come suddividere i dati definendo una colonna come colonna distribuzione colonna. 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 utilizzare una colonna con un numero elevato di valori distinti che in genere verranno usati per raggruppare le righe correlate. Ad esempio, in una tabella per un sistema di e-commerce che archivia informazioni sugli ordini dei clienti, l'ID cliente potrebbe essere una colonna di distribuzione ragionevole. Tutti gli ordini per un determinato cliente verranno mantenuti nella stessa partizione, ma gli ordini per tutti i clienti verranno distribuiti tra le partizioni.

È anche possibile creare tabelle di riferimento. Queste tabelle contengono dati di ricerca, ad esempio i nomi delle città o dei codici di stato. Una tabella di riferimento viene replicata interamente in ogni nodo di lavoro. I dati in 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 viene archiviata nel nodo coordinatore. Usare tabelle locali per contenere tabelle di piccole dimensioni con dati che potrebbero non essere richiesti dai join. Gli esempi includono i nomi degli utenti e i relativi dettagli di accesso.

Replicare i dati in Database di Azure per PostgreSQL

Le repliche di sola lettura sono utili per la gestione di carichi di lavoro a elevato utilizzo di lettura. Le connessioni client possono essere distribuite tra repliche, semplificando il carico su una singola istanza del servizio. Se i client si trovano in aree diverse del mondo, si usa la replica tra aree per posizionare i dati vicino a ogni set di client e ridurre la latenza.

È anche possibile usare repliche come parte di un piano di emergenza per il ripristino di emergenza. Se il server master non è più disponibile, potrebbe essere comunque possibile connettersi a una replica.

Nota

Se il master viene perso o eliminato, tutte le repliche di sola lettura diventano invece server di lettura/scrittura. Tuttavia, questi server saranno indipendenti l'uno dall'altro, pertanto tutte le modifiche apportate ai dati in un server non verranno copiate nei server rimanenti.

Definizione di una replica

Una replica di sola lettura contiene una copia dei database contenuti nel server originale, denominata master. Usare il portale di Azure o l'interfaccia della riga di comando per creare una replica di un master.

immagine che mostra la pagina Replica per il servizio Database di Azure per PostgreSQL

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 modifica dei dati avrà esito negativo.

Ritardo replica

La replica non è sincrona e le modifiche apportate ai dati nel server master potrebbero richiedere del tempo per essere visualizzate nelle repliche. Le applicazioni client che si connettono alle repliche devono essere in grado di gestire questo livello di coerenza finale. Monitoraggio di Azure consente di tenere traccia del ritardo di tempo nella replica usando le metriche max lag across repliche e replica lag.

Gestione e monitoraggio

È possibile usare strumenti familiari, ad esempio pgAdmin per connettersi a Database di Azure per PostgreSQL per gestire e monitorare i database. Tuttavia, alcune funzionalità incentrate sul server, ad esempio l'esecuzione di backup e ripristino del server, non sono disponibili perché il server è gestito e gestito da Microsoft.

Immagine che mostra lo strumento pgAdmin connesso al database di Azure per PostgreSQL

Strumenti di Azure per il monitoraggio di Database di Azure per PostgreSQL

Azure offre un set completo di servizi usati per monitorare le prestazioni del server e del database e risolvere i problemi. Questi servizi consentono di visualizzare il modo in cui PostgreSQL usa le risorse di Azure allocate. Queste informazioni vengono usate per valutare se è necessario ridimensionare il sistema, modificare la struttura delle tabelle e degli indici nei database e visualizzare le statistiche di runtime e altri eventi. I servizi disponibili includono:

  • Monitoraggio di Azure. Database di Azure per PostgreSQL fornisce metriche che consentono di tenere traccia degli elementi, ad esempio utilizzo della CPU e dell'archiviazione, velocità di I/O, occupazione della memoria, numero di connessioni attive e ritardo della replica:

    immagine che mostra Monitoraggio di Azure con le metriche per Database di Azure per PostgreSQL

  • log del server . Azure rende disponibili i log per ogni server PostgreSQL. È possibile scaricarli dal portale di Azure:

    Immagine che mostra i log del server per un'istanza del servizio Database di Azure per PostgreSQL

  • Query Store e Informazioni dettagliate prestazioni query. Database di Azure per PostgreSQL archivia 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, eseguire 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 ridotto, ma è possibile abilitare il rilevamento impostando la proprietà del server pg_qs.query_capture_mode per ALL o TOP.

    immagine che mostra la pagina dei parametri del server per Database di Azure per PostgreSQL

    È anche possibile configurare Query Store per acquisire informazioni sulle query che impiegano tempo in attesa. Una query potrebbe dover attendere mentre un'altra query rilascia un blocco su una tabella o perché la query esegue molte operazioni di I/O o perché la memoria è in esecuzione breve. Queste informazioni vengono visualizzate 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:

    immagine che mostra informazioni dettagliate prestazioni query

  • raccomandazioni sulle prestazioni. L'utilità Raccomandazioni per le prestazioni, disponibile anche nel portale di Azure, esamina le query eseguite dalle applicazioni. Esamina anche le strutture nel database e consiglia come organizzare i dati e se è consigliabile aggiungere o rimuovere indici.

Connettività del client

Database di Azure per PostgreSQL viene eseguito dietro un firewall. Per accedere al servizio e al database, è necessario aggiungere una regola del firewall per gli intervalli di indirizzi IP da cui si connettono i client. Se è necessario accedere al servizio dall'interno di Azure, ad esempio un'applicazione in esecuzione con Servizi 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 di sicurezza della connessione per il servizio nel portale di Azure. Aggiungere una regola per ogni intervallo di indirizzi IP client. Questa pagina viene usata anche per applicare le connessioni SSL al servizio.

Immagine che mostra la configurazione del firewall per Database di Azure per PostgreSQL

Fare clic Aggiungi IP client nella barra degli strumenti per aggiungere l'indirizzo IP del computer desktop.

Se sono state configurate repliche di sola lettura, è necessario aggiungere una regola del firewall a ognuna 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 dipendono dal linguaggio di programmazione. Sono mantenuti da terze parti indipendenti. Database di Azure per PostgreSQL supporta librerie client per Python, PHP, Node.js, Java, Ruby, Go, C# (.NET), ODBC, C e C++.

Logica di ripetizione dei tentativi client

Come accennato in precedenza, alcuni eventi, ad esempio il failover durante il ripristino a disponibilità elevata e l'aumento delle risorse della CPU, possono causare una breve perdita di connettività. Verrà eseguito il rollback di tutte le transazioni in corso. 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 per 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à comunemente usate dai database PostgreSQL, ma esistono alcune eccezioni. Se è necessaria una funzionalità non supportata, sarà necessario rielaborare il database e il codice dell'applicazione per rimuovere questa dipendenza o prendere in considerazione l'esecuzione di PostgreSQL in una macchina virtuale. In quest'ultimo caso, è necessario assumersi la responsabilità di gestire e gestire il server.

Estensioni supportate in Database di Azure per PostgreSQL

Molte funzionalità di PostgreSQL sono incapsulate nelle estensioni. Le estensioni sono pacchetti di oggetti SQL e codice archiviati nel server, che possono essere caricati in un database usando il comando CREATE EXTENSION. Database di Azure per PostgreSQL offre attualmente molte estensioni di uso comune per:

  • Tipi di dati
  • Funzioni
  • Ricerca testuale completa
  • Indici (bloom, btree_gist e btree_gin)
  • Linguaggio plpgsql
  • PostGIS
  • Molte funzioni amministrative

Si usano i pacchetti dblink e postgres_fdw per connettere un server PostgreSQL a un altro, in modo da consentire al codice in un server di accedere ai dati contenuti in un altro. In Database di Azure per PostgreSQL è possibile connettersi solo tra server creati usando Database di Azure per PostgreSQL. Non è possibile creare connessioni in uscita ai server PostgreSQL ospitati altrove, ad esempio in locale o in una macchina virtuale.

Nota

L'elenco delle estensioni supportate è costantemente in fase di revisione e può cambiare. Verrà generato un elenco delle estensioni supportate con 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 delle serie temporali. Per usare questo database, selezionare l'opzione TIMESCALEDB nel parametro del server shared_preload_libraries e quindi riavviare il server.

Supporto del linguaggio per stored procedure e trigger

Il supporto per i linguaggi diversi da plpgsql richiede in genere di compilare separatamente la stored procedure o il codice trigger e caricare la libreria compilata nel server. Principalmente a causa di motivi di sicurezza, non è possibile farlo con Database di Azure per PostgreSQL. Se è stato scritto codice in altri linguaggi, sarà necessario convertirlo in plpgsql.