Auch eine SQL-Datenbank eignet sich als Event-Store

Event-Sourcing ist laut dem Titel der dotnetpro 12/2013 eine "geile Technik": Jede Änderung, die ein Anwender an Daten vornimmt, resultiert in einem Event, der dann beispielsweise in einem Event-Store abgelegt wird. Der Nachteil: Die Datenbank wächst schneller als bei einer klassischen Stammdatenverwaltung. Der große Vorteil aber: Man erhält die Änderungsgeschichte eines Datensatzes für lau. Eine Undo-Funktion zu implementieren ist sehr einfach.

dotnetpro: Event-Sourcing scheint ja eine tolle Technologie zu sein - zumindest in der Theorie. Aber taugt sie auch für die Praxis? Hast du sie schon eingesetzt?
Mike Bild: Wenn es um die Umsetzung von Zustandsautomaten geht, ist der Event-Sourcing-Ansatz immer eine Überlegung wert.

Auf GitHub finden sich folgende Beispielimplementationen:

 -  Tic Tac Toe
 -  RPN (Reverse Polish Notation) Taschenrechner

Weitere nicht öffentlich zugängliche Implementationen waren:

    - UI Wizards
    - Abo-Systeme wie Newsletter mit Bestätigungen
    - Warenkorb
    - Synchronisierung verteilter Daten
    - Und im Data-Analytics-Bereich habe ich schon verschiedene Mechanismen zur Erkennungen und Überwachung von Bestellung und Reservierungen umgesetzt. Beispielsweise das Filtern doppelter Bestellungen.
    - Fraud-Detection für Anwendungs-Monitoring
    - Verhaltensanalyse von Benutzern einer Anwendung über die Log-Dateien
    - Spielverhaltensanalyse mit Fraud Detection
    - Kontext bezogene Erkennung und Aussteuerung von Advertisments
    - Web-Bot Fraud Detection

Insgesamt mach ich also sehr viel in diesem Bereich. Liegt aber vielleicht auch daran, dass es ein Schwerpunkt von mir ist ;-).

Würdest du einen Event-Store als Backend für ein CMS empfehlen, ein System also, das mit Mengentext umgeht und auch mit Veränderungen von dem Mengentext?
Mike Bild: Hängt davon ab. Geht es um relativ statische Dokumente mit einem Autor - Nein. Bei einem kollaborativ schreibenden CMS macht der Einsatz eines Event-Stores aber absolut Sinn. Ein sehr gutes Beispiel dafür ist git. Gerade hier kann ein Event-getriebener Ansatz sehr viele Vorteile haben. Neben dem Aufzeichnen von Veränderungen und einer schrittweisen oder partiellen Wiederherstellung der Veränderungen des Dokuments können ein oder sogar mehrere Event-Stores (z.B. pro Dokument) sehr hohen Nutzen haben. Zudem ist gerade im Bereich Konflikterkennung und Merging bei Daten- beziehungsweise Dokumentsynchronisierung, oder Dokument-Analyse der Event-Sourcing / Event-Store Ansatz sehr gewinnbringend.

Ist auch eine SQL-Datenbank als Event-Store denkbar?
Mike Bild: Absolut, genau hier liegt die Stärke des Event-Store-Ansatzes. Letztlich ist das Medium für einen Event-Store zweitrangig. Das kann auch eine Tabelle innerhalb einer SQL-Datenbank sein. Wichtig ist hierbei der ausschließlich schreibende Zugriff (INSERT INTO) im Append-Only-Verfahren. Sollte eine SQL-Datenbank vorhanden sein, ist der Einsatz sinnvoll.

Wenn man eine SQL-Datenbank dafür verwendet, worauf muss man dann achten?
Mike Bild: Per Design sind alle notwendigen Daten innerhalb eines Events vollständig enthalten und werden ausschließlich in ein Append-Only-Datenmodel innerhalb einer Tabelle gespeichert. Das heißt, dass Events in aller Regel einer kompletten Business-Transaktion entsprechen und in aller Regel auf teuere Datenbank-Transaktion mit Isolations-Level wie Repeatable Read, Snapshot oder Serializable verzichtet werden kann. Damit genügt ein einzelner Event als Business-Transaktion den ACID-Kriterien und der Event-Store als einfache Tabelle den BASE-Kriterien.

Anders sieht es natürlich bei konkurrierenden Schreibzugriffen durch mehrere Threads oder Prozesse auf dieselbe Tabelle aus. Hierbei sollte im Falle einer SQL-Datenbank durch geeignete Isolations-Level, Auto-Increment-Id und/oder Timestamps immer auf eine korrekte Reihenfolge der Events spätestens beim Lesen zum Beispiel durch ORDER BY geachtet werden. Zusammenfassend eröffnen sich neue Möglichkeiten eines expliziten Designs geeigneter Konsistenzgrenzen und Kompensationsmechanismen. So können Lösungen mehr und mehr von einem rein technisch getriebenen Ansatz einer Datenbank hin zu Geschäftsprozessen und deren Umgang mit Ausnahmen und Fehlern modelliert werden.