Ik bracht een week door in de prachtige stad Lissabon en woonde de jaarlijkse Europese PostgeSQL-conferentie bij. Dit markeerde de 10e verjaardag sinds de eerste Europese PostgreSQL-conferentie en mijn zesde keer dat ik aanwezig was.
Eerste indrukken
De stad was geweldig, de sfeer was geweldig en het leek erop dat het een zeer productieve en informatieve week zou worden vol interessante gesprekken met intelligente en vriendelijke mensen. Dus eigenlijk is het allereerste coole dat ik in Lissabon heb geleerd, hoe geweldig Lissabon en Portugal zijn, maar ik denk dat je hier kwam voor de rest van het verhaal!
Gedeelde buffers
We woonden de trainingssessie "PostgreSQL DBA-toolbelt voor dagelijkse operaties" bij
door Kaarel Moppel (Cybertec) . Een ding dat me opviel was de instelling van shared_buffers. Aangezien shared_buffers daadwerkelijk concurreert met of een aanvulling vormt op de systeemcache, mag deze niet worden ingesteld op een waarde tussen 25% en 75% van het totale beschikbare RAM-geheugen. Dus hoewel de aanbevolen instelling voor typische workloads in het algemeen 25% RAM is, kan deze voor speciale gevallen worden ingesteld op> =75%, maar niet daartussenin.
Andere dingen die we in deze sessie hebben geleerd:
- helaas gemakkelijke online (of offline) activering/activering van data-checksums is nog niet in 11 (initdb/logische replicatie blijft de enige optie)
- Pas op voor vm.overcommit_memory, je kunt het beter uitschakelen door het in te stellen op 2. Stel vm.overcommit_ratio in op ongeveer 80.
Geavanceerde logische replicatie
In het gesprek van Petr Jelinek (2e kwadrant) , de oorspronkelijke auteurs van logische replicatie, leerden we over meer geavanceerde toepassingen van deze nieuwe opwindende technologie:
- Gecentraliseerde gegevensverzameling:we kunnen meerdere uitgevers hebben en vervolgens een centraal systeem met een abonnee op elk van die uitgevers, waardoor gegevens uit verschillende bronnen beschikbaar komen in een centraal systeem. (typisch gebruik:OLAP)
- Gedeelde wereldwijde gegevens of met andere woorden een centraal systeem voor het bijhouden van wereldwijde gegevens en parameters (zoals valuta, aandelen, markt-/grondstofwaarden, weer, enz.) die worden gepubliceerd naar een of meer abonnees. Dan worden deze gegevens slechts in één systeem bijgehouden, maar zijn ze beschikbaar voor alle abonnees.
- Logische replicatie kan asynchroon maar ook synchroon zijn (gegarandeerd bij commit)
- Nieuwe mogelijkheden met logische decodering:
- integratie met Debezium/Kafka via plug-ins voor logische decodering
- wal2json-plug-in
- Bidirectionele replicatie
- Upgrades van bijna nul downtime:
- logische replicatie instellen op de nieuwe server (mogelijk initdb met inschakelen van data-checksums)
- wacht tot de vertraging relatief klein is
- van pgbouncer pauzeer de database(s)
- wacht tot de vertraging nul is
- wijzig de pgbouncer-configuratie zodat deze naar de nieuwe server verwijst, herlaad de conf van pgbouncer
- van pgbouncer hervat de database(s)
Wat is er nieuw in PostgreSQL 11
In deze spannende presentatie, Magnus Hagander (Redpill Linpro AB) introduceerde ons de wonderen van PostgreSQL 11:
- pg_stat_statements ondersteunt query-id van 64-bits.
- pg_prewarm (een methode om de systeemcache of gedeelde buffers op te warmen):toevoeging van nieuwe configuratieparameters
- Nieuwe standaardrollen maken het gemakkelijk om afstand te nemen van postgres (de gebruiker bedoel ik :) )
- Opgeslagen procedures met xactionele controle
- Geavanceerd zoeken in volledige tekst
- Logische replicatie ondersteunt TRUNCATE
- Basisback-ups (pg_basebackup) checksums valideren
- Verschillende verbeteringen in het parallelliseren van zoekopdrachten
- Partitionering nog verfijnder dan in 10
- standaardpartitie
- updates tussen partities (verplaatst rij van de ene partitie naar de andere)
- lokale partitie-indexen
- unieke sleutel voor alle partities (nog steeds geen referentie)
- hash-partitionering
- partitiegewijs joins
- partitiegewijze aggregaten
- partities kunnen vreemde tabellen zijn op verschillende vreemde servers. Dit opent geweldige mogelijkheden voor fijnkorrelige sharding.
- JIT-compilatie
zheap:een antwoord op PostgreSQL Bloat Woes
Dit is nog steeds niet in 11, maar het klinkt zo veelbelovend dat ik het in de lijst met coole dingen moest opnemen. De presentatie werd gegeven door Amit Kapila (EnterpriseDB) een van de belangrijkste auteurs van deze nieuwe technologie die uiteindelijk als alternatief soort heap in de PostgreSQL-kern wil worden geïntegreerd. Dit wordt geïntegreerd met de nieuwe Pluggable Storage API in PostgreSQL, die meerdere Table Access-methoden gaat ondersteunen (op dezelfde manier als de verschillende [Index] Access-methoden die in mijn eerste blog worden behandeld).
Dit zal proberen de chronische tekortkomingen van PostgreSQL op te lossen met:
- tafelzwelling
- moeten (automatisch) stofzuigen
- mogelijk een transactie-id omhulling
Al deze zaken zijn geen probleem voor het gemiddelde middelgrote tot grote bedrijf (hoewel dit zeer relatief is), we kennen banken en andere financiële instellingen die PostgreSQL van tientallen TB's aan gegevens en verscheidene duizenden transacties/sec zonder problemen uitvoeren. Opgeblazenheid van de tabel wordt afgehandeld door autovacuüm en het bevriezen van rijen lost het probleem van transactie-id-omhulling op, maar dit is nog steeds niet onderhoudsvrij. De PostgreSQL-gemeenschap werkt aan een echt onderhoudsvrije database, daarom wordt de zheap-architectuur voorgesteld. Dit brengt:
- een nieuw UNDO-logboek
- UNDO log maakt gegevens zichtbaar voor oude transacties die de oude versies zien
- UNDO zal worden gebruikt om de effecten van afgebroken transacties ongedaan te maken
- veranderingen vinden plaats. Oude versies worden niet langer bewaard in de gegevensbestanden.
Doelen op hoog niveau:
- betere controle van het opgeblazen gevoel
- minder schrijfacties
- kleinere tuple-headers
Dit zal PostgreSQL in dit opzicht op één lijn brengen met MySql en Oracle.
Parallelle zoekopdracht in PostgreSQL:hoe gebruik je het niet (mis)?
In deze presentatie door Amit Kapila en Rafia Sabih (EnterpriseDB) leerden we de innerlijke stukjes van parallellisatie en ook tips om veelvoorkomende fouten te vermijden, evenals enkele aanbevolen GUC-instellingen:
- parallelisme ondersteunt alleen B-tree-indexen
- max_parallel_workers_per_gather ingesteld op 1→ 4 (afhankelijk van beschikbare cores)
- let op de volgende instellingen:
- parallel_tuple_cost:kosten van het overzetten van een tuple van een parallel werkproces naar een ander proces
- parallel_setup_cost:kosten voor het starten van parallelle werknemers en het initialiseren van dynamisch gedeeld geheugen
- min_parallel_table_scan_size:de minimale grootte van relaties waarmee rekening moet worden gehouden voor parallelle sequentiescan
- min_parallel_index_scan_size:de minimumgrootte van de index die in aanmerking komt voor een parallelle scan
- random_page_cost:geschatte kosten voor toegang tot een willekeurige pagina op schijf