Vom Wechsel von relationalen Daten zu Ereignissen

Leitfaden für den Wechsel von relationalen Daten zu Ereignissen

• In der Kirche des Event Sourcings werden Geschäftsdaten nicht verloren, sondern als Ereignisse bewahrt.
• Ereignisse stellen eingetretene Tatsachen dar und werden nach jeder Aktion gespeichert.
• Ein Event-Stream ist die Liste aller aufgezeichneten Ereignisse, ist unveränderlich und frühere Fehler können durch das Hinzufügen neuer Ereignisse korrigiert werden.

1. Statusspalten finden

• Die Werte von Statusspalten können Phasen im Lebenszyklus von Daten widerspiegeln.
• Zum Beispiel kann eine Bestellung gestartet, versendet und bezahlt werden.
• Diese Zustände können in Ereignisse wie Order Initiated, Order Shipped und Order Paid umgewandelt werden.

2. Datumsspalten prüfen

• Datumsspalten können Informationen über wichtige Ereignisse in einem Prozess liefern.
• ShipmentDate, DeliveryDate und OrderPlacementDate zeigen geschäftliche Begriffe auf und können helfen, neue Ereignisse einzuführen.

3. Selektivität von Spalten analysieren

• Nullable-Spalten können optional sein oder erst später bereitgestellt werden.
• Pflichtspalten sollten bereits im ersten Order Initiated-Ereignis enthalten sein.

4. Nach Tabellen mit den meisten 1:n-Beziehungen suchen

• Beim Event Sourcing werden Daten rund um Geschäftsprozesse gruppiert, um eine effiziente Verarbeitung zu erreichen.
• Tabellen mit vielen 1:n-Beziehungen können Kandidaten für Stream-Typen sein.

5. Explizite Ereignisse einführen

• Bei der Migration relationaler Daten in Ereignisse sollten neu entdeckte Ereignisse nicht während des Imports wiederverwendet werden; stattdessen sollte explizit ein Order Imported-Ereignis bereitgestellt werden.

6. Experimentieren und validieren

• Man sollte Prototypen in einer sicheren Umgebung ausprobieren, die Ergebnisse mit den Erwartungen vergleichen und ohne Hast iterativ vorgehen.

Meinung von GN⁺

• Das Wichtigste an diesem Artikel ist die Bedeutung eines neuen Ansatzes zur Bewahrung von Geschäftsdaten beim Übergang von relationalen Datenbanken zu Event Sourcing.
• Interessant ist der Artikel, weil er einen Weg zeigt, den Lebenszyklus von Daten besser zu verstehen und zu nutzen, statt bei herkömmlichen Methoden der Datenverwaltung zu bleiben.
• Event Sourcing kann nicht nur aus technischer Sicht nützlich sein, sondern auch dabei helfen, ein gemeinsames Verständnis zwischen Business- und Technikteams aufzubauen.

[GN⁺]

Hacker-News-Kommentar

• Empfehlung für die Nutzung von PostgreSQL und FOSS-Reporting-Tools

  • Wenn in der Anwendung bereits PostgreSQL verwendet wird, wird empfohlen, Event-Daten in PostgreSQL zu speichern und FOSS-Reporting-Tools wie Apache Superset oder Metabase zu nutzen.
  • PostgreSQL wird genutzt, bis die Datenmenge etwa 2 TB erreicht; danach wird entschieden, ob 2 TB an Daten online benötigt werden oder ob nur tägliche/stündliche Zusammenfassungen nötig sind.
  • In einem Fall bei einem Kunden werden mehr als 10 TB an Daten und 1500 Events pro Sekunde verarbeitet; Detaildaten bleiben 2 Tage online, der Rest wird zusammengefasst nach S3 verschoben und kann über Athena SQL abgefragt werden.
  • Mit AWS RDS Multi-AZ wird automatisches Failover unterstützt, und ein einzelner Engineer betreibt und verwaltet das gesamte System mit weniger als 5 Stunden Aufwand pro Monat.
  • PostgreSQL bietet ein einziges System, in dem Daten an einem Ort gespeichert, erlernt, verwaltet und skaliert werden können.
  • Auch nichttechnische Mitarbeitende können in Systemen wie Metabase oder Preset einfach Diagramme erstellen.
  • PostgreSQL entwickelt sich jedes Jahr weiter, und bei Bedarf ist zusätzliche Skalierung über PostgreSQL-kompatible Systeme wie Aurora, TimescaleDB oder CitusDB möglich.

• Wann eine eventgetriebene Architektur sinnvoll ist

  • Wenn ein Kunde eine bestimmte Aktion ausführt und eine Antwort erwartet, handelt es sich nicht um Event-Driven, sondern um ein Request/Response-Muster.
  • Event-Driven bedeutet, dass etwas in unerwarteten Situationen geschieht, zum Beispiel wenn ein Build ausgelöst wird, nachdem Code auf GitHub gepusht wurde.

• Geteilte skeptische Erfahrung mit Event Sourcing

  • Ein Team hat Event Sourcing in Betracht gezogen, sich aber letztlich dagegen entschieden, weil kein klarer Vorteil erkennbar war und das Risiko, etwas Neues auszuprobieren, zu hoch erschien.
  • Es gibt kein Bedauern darüber, eine Lernchance verpasst zu haben; vielmehr wird es positiv bewertet, sich nicht ohne Not auf ein komplexes Problem einzulassen.

• Nützlichkeit von Domain Event Modeling

  • Domain Event Modeling ist nützlich für die Kommunikation mit Domain-Expertinnen und -Experten, die das zu lösende Problem verstehen.
  • Wenn ein System implementiert werden soll, das einen Audit-Trail für eine State Machine über lange Zeiträume bereitstellt, ist es besser, Tools wie Temporal.io/durable functions zu verwenden.
  • Solche Tools verwenden intern Event Sourcing und zwingen dazu, Code unter Berücksichtigung von Deduplizierung und Idempotenz zu schreiben.

• Fragen zur Implementierung von Event Sourcing

  • Es fehlt an Erklärungen dazu, wie sich der aktuelle Zustand effizient aus einem Event-Stream rekonstruieren lässt und wie ein Event-Stream in einer Datenbank modelliert werden sollte.

• Bottom-up vs. Top-down, maßgeschneidert vs. allgemein einsetzbar

  • Der Top-down-Ansatz beginnt bei der Business-Domain und bildet die Implementierung auf verfügbare Technologien, Tools und Anbieter ab.
  • Der Bottom-up-Ansatz beginnt bei verfügbaren Technologien, Tools und Anbietern und kombiniert daraus eine funktionierende Lösung.
  • Der maßgeschneiderte Ansatz umfasst DDD, CQRS/ES, Sagas, TBUI, GraphQL, algebraische Datentypen usw.
  • Der allgemeine Ansatz umfasst RDBMS, CRUD, REST, ACID-Transaktionen, CDC, allgemeine Verwaltungs-UIs, No-Code/Low-Code sowie eingeschränkte/allgemeine Typen.

• Unterstützung und Kritik an eventbasierter Architektur

  • Es gibt Unterstützung für eventbasierte Architekturen, aber der betreffende Artikel scheitert daran, seine Argumentation klar zu vermitteln.
  • Wenn man sich auf den Unterschied zwischen Datenbeziehungen und Geschäftsverhalten konzentriert, wird klarer, warum man sich von einem operativen relationalen Datenspeicher lösen möchte.

• Die Notwendigkeit von Relationen trotz Event Sourcing

  • Trotz der vielen Vorteile von Event Sourcing werden Relationen weiterhin benötigt.
  • Wenn sämtliche Relationen nur implizit im Code der Anwendungsschicht enthalten sind, ist das nicht akzeptabel.
  • Es wird eine Möglichkeit benötigt, Relationen abzufragen oder relationale Sichten aktuell zu halten.

• Unterstützung für relationale Daten

  • Es wurde entschieden, Komplexität zu vermeiden und bei traditionellen relationalen Daten zu bleiben.

• Neue Erkenntnis zu eventgetriebenem Design

  • Eventgetriebenes Design wurde erst vor Kurzem entdeckt, und beim Nachdenken über optimale Datenstrukturen in einer von KI dominierten Welt wurde ein ähnliches Fazit erreicht.
  • Wenn eventgetriebenes Design dabei hilft, Komplexität zu beherrschen und Daten tatsächlich nutzbar zu machen, wird es als wertvoll angesehen.
  • Es wird erwartet, dass eventgetriebenes Design in den kommenden Jahren allgemein verbreitet sein wird, wenn KI Wissen über alle Business-Events haben und diese abfragen kann.