Fünf coole Dinge, die ich auf der PostgreSQL Conference Europe 2018 gelernt habe

Ich verbrachte eine Woche in der großartigen Stadt Lissabon und nahm an der jährlichen European PostgeSQL Conference teil. Dies war der 10. Jahrestag seit der ersten europäischen PostgreSQL-Konferenz und meine sechste Teilnahme.

Erster Eindruck

Die Stadt war großartig, die Atmosphäre war großartig und es schien eine sehr produktive und informative Woche voller interessanter Gespräche mit intelligenten und freundlichen Menschen zu werden. Das allererste Coole, was ich in Lissabon gelernt habe, war also, wie großartig Lissabon und Portugal sind, aber ich schätze, für den Rest der Geschichte bist du hierher gekommen!

Gemeinsam genutzte Puffer

Wir haben an der Schulung „PostgreSQL DBA-Toolbelt für den täglichen Betrieb“

von Kaarel Moppel (Cybertec) . Eine Sache, die mir aufgefallen ist, war die Einstellung von shared_buffers. Da shared_buffers tatsächlich den Cache des Systems konkurriert oder ergänzt, sollte es nicht auf einen Wert zwischen 25 % und 75 % des insgesamt verfügbaren RAM gesetzt werden. Während also im Allgemeinen die empfohlene Einstellung für typische Workloads 25 % des Arbeitsspeichers beträgt, könnte sie in besonderen Fällen auf>=75 % festgelegt werden, aber nicht dazwischen.

Andere Dinge, die wir in dieser Sitzung gelernt haben:

• Leider ist die einfache Online- (oder Offline-) Aktivierung/Aktivierung von Datenprüfsummen noch nicht in 11 enthalten (initdb/logische Replikation bleibt die einzige Option)
• Vorsicht vor vm.overcommit_memory, Sie deaktivieren es besser, indem Sie es auf 2 setzen. Setzen Sie vm.overcommit_ratio auf etwa 80.

Erweiterte logische Replikation

Im Vortrag von Petr Jelinek (2. Quadrant) , den ursprünglichen Autoren der logischen Replikation, haben wir etwas über fortgeschrittenere Anwendungen dieser neuen, aufregenden Technologie erfahren:

• Zentralisierte Datenerfassung:Wir haben möglicherweise mehrere Herausgeber und dann ein zentrales System mit einem Abonnenten für jeden dieser Herausgeber, wodurch Daten aus verschiedenen Quellen in einem zentralen System verfügbar sind. (typische Verwendung:OLAP)
• Geteilte globale Daten oder mit anderen Worten ein zentrales System zur Verwaltung globaler Daten und Parameter (wie Währungen, Aktien, Markt-/Warenwerte, Wetter usw.), die an einen oder mehrere Abonnenten veröffentlicht werden. Dann werden diese Daten nur noch in einem System gepflegt, sind aber bei allen Abonnenten verfügbar.
• Die logische Replikation kann asynchron, aber auch synchron sein (bei Commit garantiert)
• Neue Möglichkeiten mit logischer Dekodierung:
• Integration mit Debezium/Kafka über Plug-ins für logische Dekodierung
  • wal2json-Plugin
  • Bidirektionale Replikation
• Upgrades mit nahezu null Ausfallzeiten:
  • Richten Sie die logische Replikation auf dem neuen Server ein (möglicherweise initdb mit aktivierten Datenprüfsummen)
  • warten Sie, bis die Verzögerung relativ gering ist
  • von pgbouncer pausieren Sie die Datenbank(en)
  • warten, bis die Verzögerung null ist
  • pgbouncer-Konfiguration so ändern, dass sie auf den neuen Server zeigt, pgbouncer-Konf neu laden
  • von pgbouncer die Datenbank(en) fortsetzen

Was ist neu in PostgreSQL 11

In dieser spannenden Präsentation, Magnus Hagander (Redpill Linpro AB) stellte uns die Wunder von PostgreSQL 11 vor:

• pg_stat_statements unterstützt queryid von 64-Bit.
• pg_prewarm (eine Methode zum Aufwärmen des Systemcaches oder gemeinsam genutzter Puffer):Hinzufügen neuer Konfigurationsparameter
• Neue Standardrollen, die den Wechsel von Postgres (den Benutzer, den ich meine :)) erleichtern.
• Gespeicherte Prozeduren mit xaktionaler Kontrolle
• Erweiterte Volltextsuche
• Die logische Replikation unterstützt TRUNCATE
• Basissicherungen (pg_basebackup) validieren Prüfsummen
• Mehrere Verbesserungen bei der Parallelisierung von Abfragen
• Partitionierung noch raffinierter als in 10
  • Standardpartition
  • Aktualisiert partitionsübergreifend (bewegt Zeilen von einer Partition zur anderen)
  • lokale Partitionsindizes
  • eindeutiger Schlüssel über alle Partitionen (noch nicht referenzierbar)
  • Hash-Partitionierung
  • partitionsweise Verknüpfungen
  • partitionsbezogene Aggregate
  • Partitionen können fremde Tabellen auf verschiedenen fremden Servern sein. Dies eröffnet großartige Möglichkeiten für feinkörnigeres Sharding.
• JIT-Kompilierung

zheap:Eine Antwort auf die Probleme von PostgreSQL Bloat

Das ist immer noch nicht in 11, aber es klingt so vielversprechend, dass ich es in die Liste der coolen Dinge aufnehmen musste. Die Präsentation wurde von Amit Kapila (EnterpriseDB) gehalten einer der Hauptautoren dieser neuen Technologie, die darauf abzielt, schließlich als alternative Art von Heap in den PostgreSQL-Kern integriert zu werden. Dies wird in die neue Pluggable Storage API in PostgreSQL integriert, die mehrere Tabellenzugriffsmethoden unterstützen wird (genauso wie die verschiedenen [Index]-Zugriffsmethoden, die in meinem ersten Blog behandelt werden).

Dies wird versuchen, die chronischen Mängel zu beheben, die PostgreSQL hat mit:

• Aufblasen der Tabelle
• müssen (automatisch) saugen
• möglicherweise ein Transaktions-ID-Wraparound

All dies ist kein Problem für das durchschnittliche mittlere bis große Unternehmen (obwohl dies sehr relativ ist), wir kennen Banken und andere Finanzinstitute, die PostgreSQL mit Dutzenden von TB an Daten und mehreren 1000 Transaktionen/Sek. ohne Probleme ausführen. Das Aufblähen von Tabellen wird durch Autovacuum gehandhabt, und das Einfrieren von Zeilen löst das Problem des Transaktions-ID-Wraparounds, aber dies ist immer noch nicht wartungsfrei. Die PostgreSQL-Community arbeitet an einer wirklich wartungsfreien Datenbank, daher wird die zheap-Architektur vorgeschlagen. Dies bringt:

• ein neues UNDO-Log
• UNDO-Protokoll macht Daten für alte Transaktionen sichtbar, die die alten Versionen sehen
• UNDO wird verwendet, um die Auswirkungen abgebrochener Transaktionen rückgängig zu machen
• Änderungen treten an Ort und Stelle auf. Alte Versionen werden nicht mehr in den Dateien aufbewahrt.

Übergeordnete Ziele:

• bessere Blähkontrolle
• weniger Schreibvorgänge
• kleinere Tupel-Header

Dies bringt PostgreSQL in dieser Hinsicht auf Augenhöhe mit MySql und Oracle.

Parallele Abfrage in PostgreSQL:Wie sollte man sie nicht (falsch) verwenden?

In dieser Präsentation von Amit Kapila und Rafia Sabih (EnterpriseDB) haben wir die inneren Aspekte der Parallelisierung und auch Tipps zur Vermeidung häufiger Fehler sowie einige empfohlene GUC-Einstellungen kennengelernt:

• Parallelität unterstützt nur B-Tree-Indizes
• max_parallel_workers_per_gather auf 1→4 gesetzt (abhängig von den verfügbaren Kernen)
• achten Sie auf folgende Einstellungen:
  • parallel_tuple_cost:Kosten für die Übertragung eines Tupels von einem parallelen Arbeitsprozess zu einem anderen Prozess
  • parallel_setup_cost:Kosten für den Start paralleler Worker und die Initialisierung des dynamischen gemeinsam genutzten Speichers
  • min_parallel_table_scan_size:die minimale Größe der Relationen, die für den parallelen Sequenzscan berücksichtigt werden sollen
  • min_parallel_index_scan_size:die minimale Indexgröße, die für einen parallelen Scan berücksichtigt werden soll
  • random_page_cost:geschätzte Kosten für den Zugriff auf eine zufällige Seite auf der Festplatte