Detta är en fortsättning på mitt tidigare blogginlägg där jag hade berört ett ämne om PostgreSQL -tillägg. PostgreSQL-tillägg är en plug and play-uppsättning förbättringar som lägger till en extra funktionsuppsättning till ett PostgreSQL-kluster. Vissa av dessa funktioner är så enkla som att läsa eller skriva till en extern databas medan andra kan vara en sofistikerad lösning för att implementera databasreplikering, övervakning, etc.
PostgreSQL har under åren utvecklats från ett enkelt ORDBMS med öppen källkod till ett kraftfullt databassystem med över 30 års aktiv utveckling som erbjuder tillförlitlighet, prestanda och alla ACID-kompatibla funktioner. Med PostgreSQL 12 som släpptes för några månader sedan blir denna databasprogramvara bara större, bättre och snabbare.
Ibland behövde tillägg läggas till i ett PostgreSQL-kluster för att uppnå förbättrad funktionalitet som inte var tillgänglig i den inbyggda koden, eftersom de antingen inte utvecklades på grund av tidsbrist eller på grund av otillräckliga bevis på databas för kantfall. problem. Jag kommer att diskutera några av mina favorittillägg utan särskild ordning, med några demos som används av utvecklare och DBA:er.
Vissa av dessa tillägg kan behöva inkluderas i serverparametern shared_preload_libraries som en kommaseparerad lista för att förladdas vid serverstarten. Även om de flesta av tilläggen ingår i bidragsmodulen för källkoden, måste vissa laddas ner från en extern webbplats som endast är dedikerad till PostgreSQL-tillägg som kallas PostgreSQL Extension Network.
I denna tvådelade bloggserie kommer vi att diskutera tillägg som används för att komma åt data (postgres_fwd) och krympa eller arkivera databaser (pg_partman). Ytterligare tillägg kommer att diskuteras i den andra delen.
postgres_fdw
postgres_fdw är ett främmande dataomslagstillägg som kan användas för att komma åt data som lagras på externa PostgreSQL-servrar. Detta tillägg liknar ett äldre tillägg som heter dblink men det skiljer sig från sin föregångare genom att erbjuda standardkompatibel syntax och bättre prestanda.
De viktiga komponenterna i postgres_fdw är en server, en användarmappning och en främmande tabell. Det tillkommer en mindre overhead till den faktiska kostnaden för att utföra frågor mot fjärrservrar, vilket är kommunikationsoverheaden. Tillägget postgres_fdw kan också kommunicera med en fjärrserver som har en version ända upp till PostgreSQL 8.3, och är således bakåtkompatibel med tidigare versioner.
Demo
Demon kommer att visa en anslutning från PostgreSQL 12 till en PostgreSQL 11-databas. Pg_hba.conf-inställningarna har redan konfigurerats för att servrarna ska prata med varandra. Tilläggskontrollfilerna måste laddas in i den delade PostgreSQL-hemkatalogen innan tillägget skapas från Inside ett PostgreSQL-kluster.
Fjärrserver:
$ /usr/local/pgsql-11.3/bin/psql -p 5432 -d db_replica postgres
psql (11.3)
Type "help" for help.
db_replica=# create table t1 (sno integer, emp_id text);
CREATE TABLE
db_replica=# \dt t1
List of relations
Schema | Name | Type | Owner
--------+------+-------+----------
public | t1 | table | postgres
db_replica=# insert into t1 values (1, 'emp_one');
INSERT 0 1
db_replica=# select * from t1;
sno | emp_id
-----+---------
1 | emp_one
(1 row)Källserver:
$ /database/pgsql-12.0/bin/psql -p 5732 postgres
psql (12.0)
Type "help" for help.
postgres=# CREATE EXTENSION postgres_fdw;
CREATE EXTENSION
postgres=# CREATE SERVER remote_server
postgres-# FOREIGN DATA WRAPPER postgres_fdw
postgres-# OPTIONS (host '192.168.1.107', port '5432', dbname 'db_replica');
CREATE SERVER
postgres=# CREATE USER MAPPING FOR postgres
postgres-# SERVER remote_server
postgres-# OPTIONS (user 'postgres', password 'admin123');
CREATE USER MAPPING
postgres=# CREATE FOREIGN TABLE remote_t1
postgres-# (sno integer, emp_id text)
postgres-# server remote_server
postgres-# options (schema_name 'public', table_name 't1');
CREATE FOREIGN TABLE
postgres=# select * from remote_t1;
sno | emp_id
-----+---------
1 | emp_one
(1 row)
postgres=# insert into remote_t1 values (2,'emp_two');
INSERT 0 1
postgres=# select * from remote_t1;
sno | emp_id
-----+---------
1 | emp_one
2 | emp_two
(2 rows)SKRIV-operationen från källservern återspeglar fjärrservertabellen omedelbart. En liknande tillägg som heter oracle_fdw finns också som möjliggör READ- och WRITE-åtkomst mellan PostgreSQL- och Oracle-tabeller. Utöver det finns det ett annat tillägg som heter file_fdw som möjliggör dataåtkomst från platta filer på disken. Se den officiella dokumentationen för postgres_fdw som publiceras här, för mer information och detaljer.
pg_partman
När databaser och tabeller växer finns det alltid ett behov av att krympa databaser, arkivera data som inte behövs eller åtminstone partitionera tabeller i olika mindre fragment. Detta är så att frågeoptimeraren bara besöker de delar av tabellen som uppfyller frågevillkoren, istället för att skanna hela högen av tabeller.
PostgreSQL har erbjudit partitioneringsfunktioner under lång tid, inklusive Range, List, Hash och Sub-partitioning tekniker. Det kräver dock en hel del administration och hanteringsinsatser som att definiera underordnade tabeller som ärver egenskaper för en överordnad tabell för att bli dess partitioner, skapa triggerfunktioner för att omdirigera data till en partition och ytterligare skapa triggers för att anropa dessa funktioner, etc. Detta är där pg_partman kommer in i bilden, där alla dessa problem tas om hand automatiskt.
Demo
Jag kommer att visa en snabb demo av att ställa in saker och infoga exempeldata. Du kommer att se hur data som infogas i huvudtabellen automatiskt omdirigeras till partitionerna genom att bara ställa in pg_partman. Det är viktigt att partitionsnyckelkolumnen inte är null.
db_replica=# show shared_preload_libraries;
shared_preload_libraries
--------------------------
pg_partman_bgw
(1 row)
db_replica=# CREATE SCHEMA partman;
CREATE SCHEMA
db_replica=# CREATE EXTENSION pg_partman SCHEMA partman;
CREATE EXTENSION
db_replica=# CREATE ROLE partman WITH LOGIN;
CREATE ROLE
db_replica=# GRANT ALL ON SCHEMA partman TO partman;
GRANT
db_replica=# GRANT ALL ON ALL TABLES IN SCHEMA partman TO partman;
GRANT
db_replica=# GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA partman TO partman;
GRANT
db_replica=# GRANT EXECUTE ON ALL PROCEDURES IN SCHEMA partman TO partman;
GRANT
db_replica=# GRANT ALL ON SCHEMA PUBLIC TO partman;
GRANT
db_replica=# create table t1 (sno integer, emp_id varchar, date_of_join date not null);
db_replica=# \d
List of relations
Schema | Name | Type | Owner
--------+------+-------+----------
public | t1 | table | postgres
(1 row)
db_replica=# \d t1
Table "public.t1"
Column | Type | Collation | Nullable | Default
--------------+-------------------+-----------+----------+---------
sno | integer | | |
emp_id | character varying | | |
date_of_join | date | | not null |
db_replica=# SELECT partman.create_parent('public.t1', 'date_of_join', 'partman', 'yearly');
create_parent
---------------
t
(1 row)
db_replica=# \d+ t1
Table "public.t1"
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
--------------+-------------------+-----------+----------+---------+----------+--------------+-------------
sno | integer | | | | plain | |
emp_id | character varying | | | | extended | |
date_of_join | date | | not null | | plain | |
Triggers:
t1_part_trig BEFORE INSERT ON t1 FOR EACH ROW EXECUTE PROCEDURE t1_part_trig_func()
Child tables: t1_p2015,
t1_p2016,
t1_p2017,
t1_p2018,
t1_p2019,
t1_p2020,
t1_p2021,
t1_p2022,
t1_p2023
db_replica=# select * from t1;
sno | emp_id | date_of_join
-----+--------+--------------
(0 rows)
db_replica=# select * from t1_p2019;
sno | emp_id | date_of_join
-----+--------+--------------
(0 rows)
db_replica=# select * from t1_p2020;
sno | emp_id | date_of_join
-----+--------+--------------
(0 rows)
db_replica=# insert into t1 values (1,'emp_one','01-06-2019');
INSERT 0 0
db_replica=# insert into t1 values (2,'emp_two','01-06-2020');
INSERT 0 0
db_replica=# select * from t1;
sno | emp_id | date_of_join
-----+---------+--------------
1 | emp_one | 2019-01-06
2 | emp_two | 2020-01-06
(2 rows)
db_replica=# select * from t1_p2019;
sno | emp_id | date_of_join
-----+---------+--------------
1 | emp_one | 2019-01-06
(1 row)
db_replica=# select * from t1_p2020;
sno | emp_id | date_of_join
-----+---------+--------------
2 | emp_two | 2020-01-06
(1 row)Detta är en enkel partitioneringsteknik men var och en av ovanstående enkla partitioner kan delas upp ytterligare i underpartitioner. Vänligen kontrollera den officiella dokumentationen för pg_partman som publiceras här, för fler funktioner och funktioner som den erbjuder.
Slutsats
Del två av den här bloggen kommer att diskutera andra PostgreSQL-tillägg som pgAudit, pg_repack och HypoPG.