AlloyDB
4 DBAs

Google fornisce un'impressionante numero di servizi in rete. Sicuramente il piu' noto e' il motore di ricerca ma il ventaglio di prodotti e' veramente molto ampio. Tra i molti servizi offerti in Cloud vi sono anche quelli relativi alle basi di dati.

AlloyDB e' un servizio in cloud di Google che fornisce una base dati compatibile con PostgreSQL ma con funzionalita' aggiuntive: e' l'oggetto di questa breve paginetta.
Questo documento descrive le caratteristiche degli ambienti AlloyDB presentando, in modo sintetico e pratico, le differenze rispetto ad un'installazione PostgreSQL on-premise.
Dopo una breve introduzione ai componenti di base (PostgreSQL, Cloud SQL e DBaaS, AlloyDB), si entra nei dettagli di AlloyDB vedendo l'architettura, l'installazione, i superpoteri dell'amministratore, e la configurazione. Si passa quindi all'utilizzo con gli accessi, il monitoring, la gestione, il backup/restore.

Per ovvie ragioni di spazio questo documento e' stato scritto per DBA PostgreSQL o quantomeno per chi PostgreSQL gia' lo conosce e lo utilizza...
Per chi non conosce PostgreSQL si consiglia la lettura di un documento introduttivo su PostgreSQL come Introduzione a PostgreSQL oppure Qualcosa in piu' su PostgreSQL ed infine del documento Statistiche prestazionali in PostgreSQL che elenca strumenti e tecniche per analizzare le prestazioni in PostgreSQL.

PostgreSQL

PostgreSQL e' considerato a ragione il piu' completo e robusto RDBMS Open Source. Le sue prestazioni ed affidabilita' sono paragonabili a quelle dei piu' diffusi RDBMS commerciali e su alcune funzionalita' e' il database di riferimento (eg. GIS). I suoi principali punti di forza sono una licenza molto aperta per tutti gli utilizzi, la gestione completa ed efficiente delle transazioni (ACID), ottime prestazioni ed affidabilita', un SQL ricco di funzionalita' (eg. subquery, referential integrity, inheritance, trigger, stored fuctions, 2PC, full-text, JSON, analytics, native partitioning, stored procedures, ...), allineato ai piu' recenti standard ed estensibile (extension), funzionalita' Object-Relational, strumenti di amministrazione e gestione completi, funzionalita' di replicazione/HA/DR incluse nel database.

La gestione delle transazioni in PostgreSQL avviene con la tecnica del MVCC (Multiversion Concurrency Control) e la consistenza dei dati su disco e' assicurata con il logging sui WAL (Write-Ahead Logging).
Un'instanza Postgres contiene piu' database. All'interno di ogni database viene mantenuto un ricco Catalog che consente di controllare con query SQL gli oggetti presenti nella base dati (eg. pg_database, pg_class, pg_tables, ...) e l'andamento delle attivita' (eg. pg_stat_activity, pg_locks, pg_settings, pg_stats,...).

L'ecosistema di applicazioni ed ambienti compatibili con Postgres e' molto ampio e completo.

Cloud SQL e DBaaS

Google offre con Cloud SQL un gestione comune che semplifica l'impostazione, il funzionamento e il dimensionamento di database relazionali nel cloud.

Le basi dati Cloud SQL sono facilmente scalabili ed automatizzano le principali attivita' di gestione del database (eg. update/upgrade, backup/restore, monitoring, storage management). Tutte le basi dati vengono gestite da console grafica oppure con la CLI (gcloud) oppure con le API rest oppure nella Cloud Shell con Terraform in modo semplice e consistente.

Google Cloud SQL rende disponibili diversi database: PostgreSQL, MySQL, Microsoft SQL Server. Sono inoltre disponibili database sviluppati da Google per il cloud come Spanner e BigQuery. Importante e' il recente accordo per fornire anche Oracle con un'implementazione multicloud. Fondamentale per le prestazioni di alcune applicazioni il Memorystore che supporta per esempio Redis e memcached. Ma sono disponibili molteplici sul Cloud di Google altri servizi anche piu' di nicchia come il database colonnare ClickHouse, PostgresML, ... e non da ultimo in questa paginetta vedremo le caratteristiche di AlloyDB!
Insomma le alternative disponibili per i servizi database in GCP sono veramente parecchie:

(Fonte: Google)

Come gli altri servizi in Cloud di Google anche i servizi Cloud SQL vengono erogati nelle diverse Region disponibili (eg. us-east1 in South Carolina, us-centra1 in Iowa, us-west1 in Oregon, europe-west8 in Italia a Milano, europe-west12 in Italia a Torino, ...). I servizi presenti ed i prezzi variano leggermente da Region a Region ma sopratutto la latenza di accesso e' differente a seconda della distanza ed e' quindi importante scegliere con attenzione dove allocare i propri ambienti. In ogni Region sono presenti piu' Availability Zones (AZs) che sono implementate con alimentazioni, reti, strutture indipendenti per garantire un'elevata alta affidabilita'.

(Fonte: Google)

Altra scelta importante e' il tipo di macchina utilizzato per ospitare i servizi applicativi e le base dati; le possibilita' sono molto ampie. Nel caso di AlloyDB e' possibile arrivare fino a 128 vCPU e 864 GB di RAM per VM.

AlloyDB

AlloyDB e' l'implementazione Google di un database compatibile a PostgreSQL. Come Cloud SQL for PostgreSQL anche AlloyDB e' una base dati gestita (eg. tuning, backup, upgrade, scale, ...) e le versioni disponibili fanno riferimento ad una precisa major version di PostgreSQL community. Ma con AlloyDB vi sono importanti differenze rispetto a PostgreSQL:

• Storage Engine: AlloyDB utilizza uno storage engine proprietario sviluppato per il Cloud ed ottimizzato sull'infrastruttura Google. Le tecniche di tiering e compressione consentono vantaggi prestazionali significativi rispetto ad un PostgreSQL standard ad esempio nella fase di scrittura del WAL, particolarmente importante per la gestione delle transazioni.
• High Availability: Con PostgreSQL e' possibile creare una configurazione in alta affidabilita' utilizzando la replica, ma questo richiede configurazioni aggiuntive ed un'opportuna gestione. Con AlloyDB le configurazioni in alta affidabilita' e la gestione del disaster recovery sono molto semplici ed efficaci.
• Query Optimization: L'ottimizzatore di AlloyDB e' stato perfezionato utilizzando anche tecniche di machine learning per tener conto della configurazione specifica presente in Cloud e per migliorare le performance delle query piu' complesse. AlloyDB consente un parallelismo piu' elevato rispetto ad una normale istanza PostgreSQL.
• Additional features: Oltre alla maggioranza delle core extension di Postgres e alle extension aggiuntive piu' utili per il Cloud, AlloyDB offre funzionalita' aggiuntive come l'Index Advisory, il Columnar Engine, l'AlloyDB AI, ...

Sono disponibili diverse versioni di AlloyDB for PostgreSQL corrispondenti a differenti versioni di PostgreSQL. Nella creazione di un cluster AlloyDB si sceglie la major version PostgreSQL di riferimento mentre l'aggiornamento delle minor version e' automatico.
AlloyDB e' anche disponibile con una versione installabile on-premises denominata AlloyDB Omni. AlloyDB Omni viene eseguito in un container e' quindi necessario utilizzare un runtime come Docker o Podman. AlloyDB Omni, essendo installato on-premises, necessita di una gestione come una normale istanza PostgreSQL e richiede l'aggiornamento manuale delle minor releases.

Le versioni disponibili di AlloyDB ed AlloyDB Omni sono riassunti nella seguente tabella:
(Source: Your database stinks Release Notes)

Oltre all'aggiornamento rispetto alle versioni di PostgreSQL e' molto importante l'evoluzione delle funzionalita' aggiuntive:
(Source: Release Notes)

In generale una versione di AlloyDB ha le stesse identiche funzionalita' della corrispondente versione di PostgreSQL. Questo e' vero dal punto di vista delle applicazioni ma vi sono pero' importanti differenze nell'architettura. Ulteriori differenze si rendono evidenti nella gestione e nell'amministrazione: nel seguito cercheremo di vedere tutte le particolarita' di AlloyDB.

Architettura AlloyDB

AlloyDB implementa una gestione separata dello storage che e' comune a tutte le istanze DB e viene automaticamente replicato su diverse Availability Zones. Una gestione specifica e' applicata ai WAL, fondamentali nell'architettura di PostgreSQL per garantire la Durability delle transazioni. Le scritture sequenziali eseguite sui WAL debbono avere una bassissima latenza per fornire il massimo delle prestazioni in Cloud.
Non e' necessario preallocare o definire la dimensione dello storage che cresce dinamicamente quando necessario.

Il Machine Type consente di scegliere la potenza dei sistemi ospite. Si parte da 2 vCPU con 16GB di RAM fino ad arrivare 128 vCPU con 864GB di RAM. Lo storage scala automaticamente fino a 64 TB.
Quando si attiva un'istanza AlloyDB in realta' viene attivato un DB Cluster. In un DB Cluster e' sempre presente un'istanza DB principale in lettura/scrittura e possono essere attive fino a 20 ulteriori istanze in sola lettura. Le istanze in sola lettura possono essere utilizzate per ridurre il carico in lettura ed e' disponibile un punto di accesso bilanciato tra le istanze in lettura.

Con una Basic Instance si dispone di ha una sola istanza senza HA, in tutti gli altri casi si hanno piu' istanze che vengono distribuite su AZ differenti.
E' possibile creare un secondary cluster su un'altra region come Disaster Recovery (DR). Il cluster secondario viene aggiornato con replica asincrona.

Installazione

Ricordate i comandi rpm o apt del sistema operativo per installare i pacchetti PosgreSQL? Dimenticatelo! Siamo in Cloud ed e' tutto diverso...

Non c'e' nessun software da installare, la creazione di un'istanza AlloyDB non richiede alcuna competenza tecnica specifica e si effettua solo con qualche click. Anche la configurazione iniziale della base dati, che tipicamente richiede competenze specifiche sul motore PostgreSQL, e' molto semplificata. Infatti Google imposta in automatico i principali parametri di tuning in modo ottimizzato. In pratica basta qualche click per scegliere il nome ed il tipo di cluster, la region, ... e viene lanciata la creazione del Cluster AlloyDB:

La creazione richiede una decina di minuti ed al termine il DB e' subito utilizzabile. A differenza di un'installazione PostgreSQL on premise non e' necessaria una configurazione iniziale. I principali parametri di tuning sono gia' configurati, il file pg_hba non deve, e non puo', essere impostato.
A volte e' opportuna qualche configurazione specifica ma questa verra' impostata con i Flag disponibili come vederemo nel seguito.

Superpoteri

Ricordate che l'utente postgres del sistema operativo ha tutti i poteri e che l'utente postgres del database ha tutti i poteri? Dimenticatelo! Siamo in Cloud ed e' tutto diverso...

Non c'e' alcun accesso al sistema operativo: i file di configurazione non si possono modificare direttamente ma vengono utilizzati i Flag, i file di log sono accessibili da console o da CLI.
Viene sempre utilizzato l'utente postgres cui va assegnata una password in fase di creazione del cluster ma... non e' superuser. L'utente superuser e' alloydbadmin che ha tutti i poteri ma che e' utilizzato solo dal Cloud per attivita' di servizio (eg. monitoring).
L'utenza postgres ha comunque tutti i diritti necessari per creare databases, per creare altri utenti, ... insomma per tutti i compiti del DBA applicativo.
Tutti gli altri utenti applicativi possono essere creati normalmente seguendo le best pratices PostgreSQL.

E' consigliato utilizzare per ogni DBA applicativo un accesso IAM (Identity and Access Management), accedere solo in modalita' crittografata e mediante l'AlloyDB Auth Proxy.

Configurazione

Ricordate i file postgresql.conf e pg_hba.conf? Dimenticatelo! Siamo in Cloud ed e' tutto diverso...

Per effettuare la configurazione di AlloyDB non e' necessario modificare alcun file. Le configurazioni si effettuano in modo molto semplice con i Flag:

     

I Flag di AlloyDB corrispondono fondamentalmente ai parametri configurabili di PostgreSQL. La maggioranza sono identici, alcuni non sono disponibili perche' impostati automaticamente, altre sono specifici di Cloud SQL e di AlloyDB.

Impostati tutti i flag che si vogliono modificare rispetto al default basta confermare l'operazione ed il cluster ripartira' con le nuove impostazioni. E' consigliabile modificare in una volta tutti i flag opportuni perche' l'attivita' di riconfigurazione del cluster richiede diverso tempo ed un breve disservizio. Le attivita' di manutenzione su AlloyDB tipicamente richiedono un tempo di preparazione piuttosto ampio (eg. 10 minuti) ma l'effettiva applicazione della modifica richiede solo un breve riavvio con un'interruzione del servizio sempre inferiore al secondo; questo vale per l'impostazione dei Flag, per le operazioni di scale-up e scale-down, ...

Accessi

Dal punto di vista dell'accesso applicativo alla base dati non presenta differenze rispetto all'utilizzo di un'istanza on premises:

psql --host=34.154.13.269 --user=postgres postgres -W
Password for user postgres: 

In pratica e' sufficiente utilizzare l'IP o, meglio, l'endopoint dell'istanza come host nella stringa di connessione.

Sulle abilitazioni delle reti, sulle connessioni SSL, sui certificati, ... ci sarebbe qualche ulteriore dettaglio da descrivere ma per semplificare diremo solo che non e' difficile!

Tipicamente gli accessi avverrano da applicazioni ospitate su Google Compute che utilizzeranno lo stesso VCP. Il protocollo utilizzato ed i driver di AlloyDB sono gli stessi di PostgreSQL, quindi ogni tool utilizzabile con PostgreSQL potra' connettersi con AlloyDB.

Monitoring

Sono molteplici le possibilita' di monitoraggio di AlloyDB. Particolarmente semplice e' il System Insights che presenta i principali dati prestazionali della VM ospite e del database:

Molto utile e' anche il Query Insights che consente di analizzare gli statement SQL:

Ma come funziona? Semplice: quando viene creato il cluster vengono creati due database di gestione: alloydbmetadata ed alloydbadmin a cui si collegano una decina di differenti agenti per il controllo dell'istanza e la raccolta delle statistiche prestazionali. Le query utilizzate sono quelle tipiche di PostgreSQL e, naturalmente, viene utilizzata l'intramontabile estensione pg_stat_statements. Se non vi sono attivita' in corso la CPU utilization rilevata da System Insights per i monitoraggi ed i processi di sistema, con un machine type da 4 vCPU, e' inferiore al 5%.

E' naturalmente sempre possibile utilizzare strumenti di terze parti per il monitoraggio sia legacy PostgreSQL (eg. pgAdmin) che specifici per GCP. Da questo punto di vista l'unica limitazione sono le autorizzazioni ma in ogni caso anche gli strumenti piu' datati funzionano perfettamente:

Backup/restore

I backup dei database AlloyDB vengono effettuati automaticamente e mantenuti per il periodo di ritenzione scelto [NdA per default 14 giorni].
I backup contengono l'intera istanza DB in tutte le sue parti. Nel caso di AlloyDB sono quindi presenti tutti i database e gli oggetti comuni ai database (eg. roles).
I restore vengono effettuati con la modalita' PITR (Point In Time Recovery) sulla stessa istanza di partenza, o scelta consigliabile, su una nuova istanza.
Con un restore e' possibile associare caratteristiche e flag differenti rispetto all'istanza di partenza. Va pero' posta attenzione che i nuovi parametri permettano di operare correttamente... e' quindi consigliato mantenere le definizioni precedenti.

Non e' possibile impostare backup parziali ma e' sempre possibile utilizzare comandi esterni per eseguire un salvataggio logico (eg. pg_dump).

Gestione

Come abbiamo visto la gestione di un'istanza AlloyDB e' differente rispetto a quella di un'istanza on-premises ma e' anche terribilmente piu' semplice!

Per riavviare un'istanza dalla console di gestione... basta un click!

Il DB cluster AlloyDB e' molto flessibile e scalabile. Quando viene richiesta una modifica l'operazione tipicamente richiede diversi minuti per la preparazione; l'applicazione della modifica poi avviene con un breve disservizio generalmente della durata di meno di un secondo. Tutte le istanze del cluster vengono automaticamente tenute allienate.
Da notare una differenza con Cloud SQL... le istanze AlloyDB non possono essere fermate.

Varie ed eventuali

Alcune funzionalita' di AlloyDB tra cui l'Engine colonnare, AlloyDB AI, AlloyDB Omni, ... richiedono una trattazione piu' ampia su una pagina dedicata [NdA appena avro' tempo cerchero' di scrivere una paginetta anche su questi argomenti].

E' interessante il confronto con il servizio Cloud SQL for PostgreSQL, il servizio di database gestito sempre fornito da Google. Molte sono le caratteristiche comuni ma AlloyDB fornisce alcune funzionalita' non presenti con PostgreSQL community. Altra differenza sono i costi, piu' alti con AlloyDB e le prestazioni che vanno pero' validate con le proprie applicazioni per verificare l'effettivo vantaggio ottenuto.

E' ancora piu' interessante il confronto con i servizi RDS di Amazon ed in particolare con Aurora PostgreSQL che, come AlloyDB e' un fork di PostgreSQL ottimizzato per l'infrastruttura Cloud. Una serie di elementi sono comuni: la separazione tra compute e storage, l'ottimizzazione dello storage in ottica cloud, la replica dei dati e la disponibilita' di istanze su piu' availability zones, il supporto della quasi totalita' delle estensioni core di PostgreSQL e l'aggiunta di ulteriori estensioni (eg. orafce, pg_cron, pg_partman, pgAudit, pgvector), gli SLA definiti, ...
Ma vi sono anche significative differenze sia tra gli ambienti Cloud di Google ed Amazon RDS che specifiche tra AlloyDB e Aurora PostgreSQL. Per citarne alcune le integrazioni in AlloyDB con BigQuery e Spanner, l'engine colonnare, le funzioni ML/AI, la possibilita' di utilizzo on-premises con AlloyDB Omni, ...; le estensioni aggiuntive come Aurora Pg Query Plan Management, la disponibilita' di differenti versioni, ...

Il documento Your server stinks! e' sempre aggiornato sui rilasci delle release PostgreSQL e di Cloud SQL.

Maggiori dettagli su AlloyDB? ... si puo' sempre guardare dentro AlloyDB!

Titolo: AlloyDB 4 PostgreSQL DBA
Livello: Avanzato (3/5)
Data: 31 Settembre 2024
Versione: 1.0.0 - 1 Ottobre 2024
Autore: mail [AT] meo.bogliolo.name