Möglichkeiten, Veränderungen in Postgres zu erfassen

• Der Artikel diskutiert verschiedene Möglichkeiten, Veränderungen in der Postgres-Datenbank zu erfassen.
• Ein Unternehmen namens Sequin synchronisiert Daten aus Drittanbieter-APIs wie Salesforce und HubSpot, damit Entwickler API-Daten mithilfe ihrer Postgres-Datenbank aufbauen können.
• Postgres bietet mehrere Optionen, um Daten in Bewegung zu erfassen, etwa das Auslösen von Workflows auf Basis von Tabellenänderungen oder das Streamen von Daten in Echtzeit an andere Datenspeicher, Systeme oder Services.
• Der einfachste Ansatz ist die Nutzung von Listen/Notify, der Interprozesskommunikationsfunktion von Postgres. Sie ist eine Implementierung des Publish-Subscribe-Musters, hat aber Einschränkungen wie eine "höchstens einmal"-Zustellsemantik und eine Begrenzung der Payload-Größe auf 8000 Byte.
• Eine weitere Methode ist das direkte Polling von Tabellen. Dabei muss jede Tabelle eine updated_at-Spalte oder etwas Ähnliches besitzen, die bei jeder Aktualisierung einer Zeile geändert wird. Diese Methode kann jedoch nicht erkennen, wann Zeilen gelöscht werden, und liefert keine Diffs.
• Postgres unterstützt Streaming-Replikation zu anderen Postgres-Datenbanken, was sich zum Erfassen von Änderungen in einer Anwendung nutzen lässt. Dieser Ansatz ist jedoch komplex und kann Anpassungen an postgresql.conf erfordern.
• Änderungen können auch über Audit-Tabellen erfasst werden, die Modifikationen protokollieren. Dieser Ansatz ähnelt der Verwendung von Replikations-Slots, ist aber manueller.
• Es gibt auch Foreign Data Wrappers (FDWs), eine Postgres-Funktion, mit der sich externe Datenquellen lesen und beschreiben lassen. Diese Methode wird jedoch nur für sehr spezifische Situationen empfohlen.
• Zusammenfassend hängt die beste Methode zur Erfassung von Änderungen in Postgres vom jeweiligen Anwendungsfall ab. Listen/Notify eignet sich gut zum Erfassen unkritischer Events, das Polling von Änderungen ist eine intuitive Lösung für einfache Anwendungsfälle, und Replikation ist die beste Wahl für eine robuste Lösung. Wenn Replikation zu schwierig ist, können Audit-Tabellen eine gute Zwischenlösung sein.

[GN⁺]

Hacker-News-Kommentare

• Der Artikel diskutiert verschiedene Methoden, um Änderungen im beliebten Datenbanksystem Postgres zu erfassen.
• Ein Kommentator empfiehlt nachdrücklich, Änderungen mithilfe von Triggern und Verlaufstabellen (Audit-Tabellen) zu erfassen, einer Technik, die seit über 30 Jahren verwendet wird.
• Der Kommentator stellt einen Link zu einem Leitfaden zur Implementierung dieser Technik bereit und warnt vor dem Einsatz von Bibliotheken zur Verlaufserfassung im Application-Bereich.
• Ein anderer Kommentator berichtet von positiven Erfahrungen mit dem Muster der Temporal Tables, das es ermöglicht, den Zustand einer Tabelle zu einem bestimmten Zeitpunkt einzusehen.
• Ein weiterer Kommentator schlägt die Verwendung von "pgaudit" vor, einer bewährten Erweiterung, die Audit-Tabellen erzeugt.
• Einige Kommentatoren diskutieren die potenziellen Risiken bestimmter Methoden, etwa das Polling einer updated_time-Spalte.
• Es gibt eine Erwähnung einer Bibliothek für Elixir-&-Postgres-Nutzer, die auf Änderungen im WAL hört.
• Einige Kommentatoren äußern, dass in diesem Bereich Innovation nötig sei, und schlagen vor, dass Postgres von einer Funktion profitieren könnte, die Abfrageergebnisse inkrementell pusht.
• Ein Kommentator warnt vor den Risiken, Änderungen per Replikation zu erfassen, und sagt, dass Postgres bei einem Stopp des Datenkonsums verpasste Daten speichern kann, bis die Festplatte voll ist.
• Derselbe Kommentator schlägt vor, zwar Polling zu verwenden, aber statt updated_at die txid zu speichern.
• Die Diskussion hebt einen Teil der Datenwelt hervor – dass es eine saubere Lösung braucht, um Abfrageergebnisse inkrementell zu pushen.