Der Teil von PostgreSQL, den wir am meisten hassen (2023)

Der Teil, den wir an PostgreSQL am meisten hassen

• PostgreSQL hat sich in den letzten fünf Jahren als das im Internet am meisten geliebte DBMS etabliert. Das liegt an seiner Zuverlässigkeit, seinem Funktionsumfang, seiner Erweiterbarkeit und daran, dass es für die meisten produktiven Workloads geeignet ist.
• Die Implementierung der Multiversion Concurrency Control (MVCC) in PostgreSQL gilt im Vergleich zu anderen relationalen DBMS jedoch als die schlechteste.

Was ist Multiversion Concurrency Control?

• Das Ziel von MVCC ist es, dass mehrere Abfragen gleichzeitig aus einer Datenbank lesen und in sie schreiben können, ohne sich gegenseitig zu stören.
• Das DBMS überschreibt bestehende Zeilen nicht, sondern hält mehrere Versionen vor, sodass Abfragen die passende Version auswählen können, um ihre Anfrage zu erfüllen.
• Dieser Ansatz macht explizite Record-Locks überflüssig und ermöglicht es Abfragen, einen Snapshot der Datenbank zu beobachten.

Multiversion Concurrency Control in PostgreSQL

• PostgreSQL verwendet beim Aktualisieren bestehender Zeilen ein append-only-Verfahren zur Versionsspeicherung, bei dem eine neue Version erzeugt wird, um Änderungen anzuwenden.
• Dieser Ansatz verursacht verschiedene komplexe Probleme.

Speicherung mehrerer Versionen

• PostgreSQL speichert alle Zeilenversionen im selben Speicherbereich.
• Bei einem Update wird ein neuer Versionsslot zugewiesen, die bestehende Version kopiert und anschließend die Änderung angewendet.
• PostgreSQL verwendet Versionsketten, um die Beziehungen zwischen den Versionen festzuhalten.

Vacuuming von Versionen

• PostgreSQL verwendet einen Vacuum-Prozess, um alte Versionen zu entfernen.
• Autovacuum läuft regelmäßig und entfernt abgelaufene Versionen, damit Speicherplatz wiederverwendet werden kann.

Warum PostgreSQLs MVCC das schlechteste ist

• Die MVCC-Implementierung von PostgreSQL stammt konzeptionell aus den 1980er-Jahren und passt nicht zu modernen Mustern log-strukturierter Systeme.
• Es werden vier Hauptprobleme erläutert, die bei PostgreSQLs MVCC auftreten.

Problem 1: Kopieren von Versionen

• PostgreSQL kopiert alle Spalten in die neue Version, was die Datenduplizierung und den Speicherbedarf erhöht.
• MySQL und Oracle vermeiden dieses Problem, indem sie Deltas speichern.

Problem 2: Tabellenaufblähung

• Abgelaufene Versionen in PostgreSQL belegen weiterhin Speicherplatz, und wenn Autovacuum sie nicht entfernt, wächst die Datenbank weiter.
• Das verschlechtert die Abfrageleistung.

Problem 3: Wartung sekundärer Indizes

• PostgreSQL muss bei jedem Update alle Indizes aktualisieren.
• Das verschlechtert die Abfrageleistung.

Problem 4: Vacuum-Management

• Die Leistung von PostgreSQL hängt stark davon ab, wie effektiv Autovacuum arbeitet.
• Wenn Autovacuum nicht richtig funktioniert, entstehen Leistungsprobleme.

Zusammenfassung von GN⁺

• PostgreSQL ist weiterhin ein sehr beliebtes DBMS, aber seine MVCC-Implementierung ist nicht modern.
• Die Behebung der MVCC-Probleme von PostgreSQL erfordert viel Zeit und Aufwand.
• Durch die Optimierung der Autovacuum-Einstellungen von PostgreSQL lässt sich die Leistung verbessern.
• Als Alternativen zur Lösung der MVCC-Probleme von PostgreSQL können MySQL und Oracle in Betracht gezogen werden.

[GN⁺]

Hacker-News-Kommentare

• OrioleDB versuchte, das Problem mit einer neuen Storage Engine zu lösen

  • Wenn hauptsächlich INSERT-Operationen stattfinden, wird kein zusätzlicher Speicherplatz benötigt
  • Es gibt eine Begrenzung für die Anzahl der Anweisungen innerhalb einer Transaktion, aber mit COPY FROM lässt sich dies umgehen
  • Aus DBA-Sicht muss kein separater Rollback-/Undo-Speicher verwaltet werden

• Das Design von PostgreSQL ist nicht in jeder Hinsicht schlecht

  • MySQL und Oracle speichern komprimierte Deltas zwischen der neuen und der aktuellen Version
  • git speichert keine Diffs, sondern wie PostgreSQL vollständige Objekte

• Die MVCC-Implementierungen von Oracle und MySQL speichern nicht die physische Adresse der neuen Version

  • Stattdessen speichern sie einen logischen Bezeichner, sodass das DBMS die physische Adresse der aktuellen Version findet
  • Dadurch können Lesezugriffe auf sekundäre Indizes langsamer werden, aber andere Vorteile reduzieren den Overhead

• Beim Aktualisieren einer einzelnen Zeile in MySQL ist SELECT id WHERE something; UPDATE what WHERE id=id deutlich schneller

  • Bei allgemeinen Workloads wird dieser Ansatz nicht verwendet, was einmalige DML langsamer macht

• In den 2010er Jahren wurde MongoDB wegen nicht-dauerhafter Schreibvorgänge als "webscale" wahrgenommen

  • Das war ein Ergebnis von Marketing

• Ich stimme der Erklärung zu pg_repack nicht zu

  • VACUUM FULL ist schwergewichtig, aber repack ist eine schnellere und leichtere Alternative

• PostgreSQL wurde aus folgenden Gründen populär

  • Datensicherheit, ACID, Ähnlichkeit mit Oracle, MVCC, Einhaltung des SQL-Standards, das Postgres-Team, die Community, Datentypen, hohe Performance, BSD-Flexibilität
  • PostgreSQL entwickelt sich kontinuierlich weiter, und die Community spielt dabei eine große Rolle

• Es gibt die Frage, ob das Speichern vollständig neuer Zeilen-Tupel-Versionen in PostgreSQL eine Eigenschaft der Standard-Storage-Engine ist

• Der Artikel war gut geschrieben und leicht zu lesen und zu verstehen

  • Er half dabei, Probleme rund um Vacuum zu verstehen, und die Diagramme waren ebenfalls gut