I Foreign Data Wrapper (FDW) in PostgreSQL
consentono di accedere a dati ospitati su una base dati esterna come se fossero
mantenuti su una normale tabella locale.
I FDW consentono di realizzare architetture dati distribuite,
sono quindi molto interessanti e lo saranno di piu' in un futuro
sempre piu' in Cloud.
Ogni nuova versione porta funzionalita' ai Postgres Foreign Data Wrapper
che risultano ora molto completi e facilmente utilizzabili per molte esigenze
di integrazione e distribuzione dei dati.
Se volete saperne di piu'... continuate a leggere!
Il documento si riferisce alla versione 11 di PostgreSQL e successive,
perche' tale versione utilizza l'estensione FDW nel modo piu' completo,
ma i contenuti valgono anche per altre versioni
[NdA in particolare dalla versione 9.6 che fornisce gia' tutte le funzionalita'
in modo completo ed efficiente].
Questo documento presenta diversi aspetti di PostgreSQL Foreign Data Wrapper:
Introduzione,
Configurazione,
Wrapper Alieni,
API,
Varie ed eventuali,
...
con un approccio pratico con esempi di comandi e query SQL.
I Foreign Data Wrappers sono un'evoluzione del modulo
dblink,
ma i FDW sono piu' trasparenti,
possono avere migliori prestazioni
e sono implementati secondo quanto previsto dallo standard ISO SQL/MED
[NdA Introdotto dallo standard SQL:2003].
La funzionalita' fornita e' quella di poter accedere a fonti date esterne
come se fossero normali tabelle locali.
I Foreign Data Wrappers sono stati introdotti nella versione PostgreSQL 9.1 con la possibilita' di accedere a Foreign Tables implementate attraverso un'API o fornite come estensione (eg. contrib/file_fdw per accedere a flat file come i .CSV).
Nella 9.3 viene rilasciato il PostgreSQL Foreign Data Wrapper:
la possibilita' nativa di accedere in modo trasparente ad altri DB Postgres.
I PostgreSQL FDW possono accedere a DB Postgres esterni
dalla versione 8.1 in sola lettura e dalla versione 8.3 anche in scrittura.
Naturalmente piu' le versioni sono vicine tra loro,
meno problematiche si hanno nell'esecuzione dell'SQL
poiche' eventuali differenze nelle funzioni utilizzate possono generare errori.
L'IMPORT FOREIGN SCHEMA e' disponibile dalla versione 9.5.
Tecnicamente e' una funzionalita' semplice (copia le DDL dal DB Source),
ma e' terribilmente comoda!
La versione 9.6 implementa il postgres_fdw pushdown.
E' una funzionalita' importante dal punto di vista prestazionale
perche' consente di effettuare in remoto operazioni di aggregazione o di join
che altrimenti erano particolamente pesanti.
La versione 11 non ha particolari differenze nell'implementazione dei FDW ma contiene diverse variazioni nell'implementazione del partizionamento. Dalla versione 11 PostgreSQL effettua la migrazione automatica delle righe tra le partizioni e questo e' supportato anche in caso di foreign partitions basate su postgres_fdw. Non e' ancora tutto... ma e' comunque un importante passo di PostgreSQL verso lo sharding in modo nativo.
Il PostgreSQL Foreign Data Wrappers e' un'estensione, quindi la sua installazione e' banale. In una normale installazione di Postgres i PFDW sono gia' presenti: basta un CREATE EXTENSION.
Ecco un esempio completo, dalla creazione dell'estensione alla definizione di una tabella esterna:
In realta' nella creazione delle tabelle risulta piu' pratico utilizzare la clausola di IMPORT che evita di avere definizioni differenti e semplifica la definizione:
Una volta creata una foreign table e' utilizzabile come tutte le altre tabelle locali!
Una volta creata una foreign table e' utilizzabile
come tutte le altre tabelle locali!
Ma ora cerchiamo le 7 piccole differenze...
Al primo accesso ad una foreign table Postgres apre una connessione verso il DB remoto. La connessione viene mantenuta e riutilizzata anche per gli accessi successivi allo stesso server/utente.
La sessione viene aperta con search_path impostato a pg_catalog, Timezone=UTC, DateStyle=ISO, IntervalStyle=postgres, extra_float_digits=3. Tale impostazione del search_path non presenta un problema per le query generate dal FDW, perche' questi inserisce in automatico il riferimento allo schema. Sono pero' possibili problemi ad eventuali trigger o regole associate all'oggetto remoto... naturalmente la soluzione e' quella di impostare in modo esplicito l'indicazione dello schema.
Le transazioni remote utilizzano sempre l'isolation level REPEATABLE READ a meno che la transazione locale non sia SERIALIZABLE, in tal caso anche in remoto viene usato SERIALIZABLE.
2PC?
Se non sapete cos'e' il 2PC... meglio lasciare stare: non sono in grado di spiegarvelo!
In ogni caso i FDW in generale non gestiscono il 2 Phase Commit.
I Foreign Data Wrapper forniti in modo nativo con la distribuzione di Postgres sono postgres_fdw e file_fdw che consentono di accedere a database PostgreSQL esterni o a file rispettivamente.
E' pero' disponibile un'ampia scelta di Wrapper per accedere ad altre tipologie di basi dati. In questo caso i wrapper non fanno parte della distribuzione ufficiale di Postgres, quindi vanno valutati di volta in volta sia la scelta delle alternative che il loro utilizzo in ambienti di produzione...
Un elenco molto completo e' riportato sul Wiki Postgres. Tra i moltissimi disponibili e' sicuramente da citare oracle_fdw, che ovviamente consente di accedere ad un database Oracle, perche' e' uno dei piu' noti.
Fin dalla prima versione in cui sono stati resi disponibili i Foreign Data Wrapper in Postgres sono state pubblicate le API per creare nuovi FDW.
Dal punto di vista tecnico non e' semplicissimo sviluppare un nuovo FDW...
ma seguendo la
documentazione ufficiale
tutto si puo' fare!
In pratica si tratta soltanto di implementare una serie di funzioni.
La documentazione ufficiale e' come sempre molto completa e chiara.
Un documento di introduzione in italiano Su PostgreSQL e' Qualcosa in piu' su PostgreSQL; il partizionamento in Postgres e' trattato in un capitolo di DIVIDE ET IMPERA ! e quindi nella paginetta Native partitioning in PostgreSQL.
Titolo: PostgreSQL Foreign Data Wrapper
Livello: Medio
Data:
31 Ottobre 2018 🎃 Halloween
Versione: 1.0.1 - 31 Ottobre 2024
Autore: mail [AT] meo.bogliolo.name