Strávil jsem týden v nádherném městě Lisabonu na každoroční evropské konferenci PostgeSQL. Bylo to 10. výročí od první evropské konference PostgreSQL a mé šesté účasti.
První dojmy
Město bylo skvělé, atmosféra byla skvělá a zdálo se, že to bude velmi produktivní a poučný týden plný zajímavých rozhovorů s inteligentními a přátelskými lidmi. Takže v podstatě úplně první skvělá věc, kterou jsem se v Lisabonu naučil, je, jak skvělé jsou Lisabon a Portugalsko, ale myslím, že jste sem přišli pro zbytek příběhu!
![](http://www.sqldat.com/article/uploadfiles/202205/2022051214472039.jpg)
![](http://www.sqldat.com/article/uploadfiles/202205/2022051214472110.jpg)
Sdílené vyrovnávací paměti
Zúčastnili jsme se školení „PostgreSQL DBA toolbelt for day-to-day ops“
autor Kaarel Moppel (Cybertec) . Jedna věc, kterou jsem zaznamenal, bylo nastavení sdílených_bufferů. Protože shared_buffers ve skutečnosti soutěží nebo doplňuje mezipaměť systému, neměla by být nastavena na žádnou hodnotu mezi 25 % a 75 % celkové dostupné paměti RAM. Takže i když je obecně doporučené nastavení pro typické pracovní zatížení 25 % RAM, ve speciálních případech by to mohlo být nastaveno na>=75 %, ale ne mezi tím.
Další věci, které jsme se v tomto sezení naučili:
- bohužel snadná online (nebo offline) aktivace/povolení kontrolních součtů dat ještě není v 11 (initdb/logická replikace zůstává jedinou možností)
- pozor na vm.overcommit_memory, raději jej deaktivujte nastavením na 2. Nastavte vm.overcommit_ratio na přibližně 80.
Pokročilá logická replikace
![](http://www.sqldat.com/article/uploadfiles/202205/2022051214472218.jpg)
V rozhovoru Petra Jelínka (2. kvadrant) , původními autory logické replikace, jsme se dozvěděli o pokročilejším využití této nové vzrušující technologie:
- Centralizované shromažďování dat:Můžeme mít několik vydavatelů a poté centrální systém s předplatitelem každého z těchto vydavatelů, který zpřístupňuje data z různých zdrojů v centrálním systému. (typické použití:OLAP)
- Sdílená globální data nebo jinými slovy centrální systém pro správu globálních dat a parametrů (jako jsou měny, akcie, tržní/komoditní hodnoty, počasí atd.), která jsou zveřejňována pro jednoho nebo více předplatitelů. Poté jsou tato data udržována pouze v jednom systému, ale jsou dostupná pro všechny předplatitele.
- Logická replikace může být asynchronní, ale také synchronní (zaručena při odevzdání)
- Nové možnosti s logickým dekódováním:
- integrace s Debezium/Kafka pomocí pluginů pro logické dekódování
- plugin wal2json
- Obousměrná replikace
- Upgrady s téměř nulovými prostoji:
- nastavit logickou replikaci na novém serveru (možná initdb s povolením kontrolních součtů dat)
- počkejte, až bude zpoždění relativně malé
- z pgbouncer pozastavte databázi (databáze)
- počkejte, až bude zpoždění nulové
- změňte konfiguraci pgbounceru tak, aby ukazovala na nový server, znovu načtěte konfigurační soubor pgbounceru
- z pgbouncer obnovte databázi(y)
Co je nového v PostgreSQL 11
![](http://www.sqldat.com/article/uploadfiles/202205/2022051214472267.jpg)
V této vzrušující prezentaci Magnus Hagander (Redpill Linpro AB) nám představil zázraky PostgreSQL 11:
- pg_stat_statements podporuje 64bitové ID dotazu.
- pg_prewarm (metoda zahřívání mezipaměti systému nebo sdílených vyrovnávacích pamětí):přidání nových konfiguračních parametrů
- Nové výchozí role usnadňující přesun od postgresu (tím myslím uživatele :) )
- Uložené procedury s xakční kontrolou
- Vylepšené fulltextové vyhledávání
- Logická replikace podporuje TRUNCATE
- Základní zálohy (pg_basebackup) ověřují kontrolní součty
- Několik vylepšení v paralelizaci dotazů
- Rozdělení ještě jemnější než v 10
- výchozí oddíl
- aktualizace napříč oddíly (přesune řádek z jednoho oddílu do druhého)
- indexy místních oddílů
- jedinečný klíč ve všech oddílech (dosud nelze odkazovat)
- rozdělení hashů
- připojení podle oddílů
- agregace podle oddílů
- oddíly mohou být cizí tabulky na různých cizích serverech. To otevírá velké možnosti pro jemnější střepiny.
- Kompilace JIT
zheap:Odpověď na PostgreSQL nadýmání
Tohle ještě není v 11, ale zní to tak slibně, že jsem to musel zařadit do seznamu super věcí. Prezentaci přednesl Amit Kapila (EnterpriseDB) jeden z hlavních autorů této nové technologie, která má být nakonec integrována do jádra PostgreSQL jako alternativní druh haldy. To bude integrováno s novým Pluggable Storage API v PostgreSQL, které bude podporovat více metod přístupu k tabulkám (stejným způsobem jako různé metody přístupu [Index] popsané v mém prvním blogu).
To se pokusí vyřešit chronické nedostatky PostgreSQL s:
- nafouknutí stolu
- potřebujete (automaticky) vysát
- potenciálně obtékání ID transakce
To vše není problém pro průměrné střední až velké firmy (ačkoli je to velmi relativní), známe banky a další finanční instituce, které provozují PostgreSQL o desítkách TB dat a několika tisícovkách transakcí/s bez problémů. Nafukování tabulky je řešeno pomocí autovakua a zmrazování řádků řeší problém obtékání id transakcí, ale stále to není bezúdržbové. Komunita PostgreSQL pracuje na skutečně bezúdržbové databázi, proto je navržena architektura zheap. To přinese:
- nový protokol UNDO
- Protokol UNDO zviditelní data pro staré transakce, které uvidí staré verze
- Zpět bude použito ke zvrácení účinků přerušených transakcí
- změny probíhají na místě. Staré verze již nejsou uchovávány v datových souborech.
Cíle na vysoké úrovni:
- lepší kontrola nadýmání
- méně zápisů
- menší n-ticová záhlaví
Tím se PostgreSQL v tomto ohledu vyrovná MySql a Oracle.
Paralelní dotaz v PostgreSQL:Jak jej (ne)nepoužívat?
V této prezentaci Amita Kapily a Rafie Sabiha (EnterpriseDB) jsme se naučili vnitřní části paralelizace a také tipy, jak se vyhnout běžným chybám, a také některá doporučená nastavení GUC:
- Paralelismus podporuje pouze indexy B-stromu
- max_parallel_workers_per_gather nastaveno na 1→ 4 (v závislosti na dostupných jádrech)
- věnujte pozornost následujícímu nastavení:
- parallel_tuple_cost:náklady na přenos jedné n-tice z paralelního pracovního procesu do jiného procesu
- parallel_setup_cost:náklady na spuštění paralelních pracovníků a inicializaci dynamické sdílené paměti
- min_parallel_table_scan_size:minimální velikost vztahů, které je třeba vzít v úvahu pro skenování paralelní sekvence
- min_parallel_index_scan_size:minimální velikost indexu, kterou je třeba vzít v úvahu při paralelním skenování
- random_page_cost:odhadované náklady na přístup k náhodné stránce na disku