Skalierbare Datenbanksysteme: ACID versus BASE

Im Rahmen unseres Vortrages „Top 10 Internet-Trends“ habe ich mich mit dem aktuellen Stand massiv skalierbarer Datenbanken beschäftigt. In der Schule haben wir alle gelernt, dass eine Datenbankmanagement-System (DBMS) vier essentiell wichtige Eigenschaften zu erfüllen hat: ACID (Atomicity, Consistency, Isolation, Durability). Technisch hat das DBMS drei Orte mit Daten (auf der Festplatte, im flüchtigen Speicher und im Transaktions-Log). Diese Zustände müssen beim „Commit“ zusammengebracht werden, was per Definition an einem einzelnen „Ort“ geschehen muss. Noch schlimmer ist, wenn die Datentöpfe auf mehrere Nodes verteilt sind. Ein Protokoll zur Synchronisation heisst Two Phase Commit und ist wird von Werner Vogels „The Unavailability Problem“ genannt.
Nun gibt es Anwendungen und Services „in the Cloud“, die riesige Datenbestände auf Tausende von Nodes (Rechner, Speicher etc.) verteilen. Problem eins ist, dass sowohl die Nodes wie auch die Verbindungen zwischen den Nodes statistisch gesehen ausfallen werden: Network Partitioning. Problem Nummer zwei ist, dass die Infrastruktur skalieren muss, am liebsten linear… Oder wie soll Google seinen WebCrawl mit über 800 TB Daten und 1 Mia. Records (Quelle: https://research.google.com/archive/bigtable.html) effizient speichern und abrufen?
Ziel ist also lineare Skalierbarkeit und Robustheit gegenüber Network Partitioning. Ja, es gibt Lösungen und sie haben einen Preis. Am besten sichtbar im neuen Mantra: ACID ist tot, es lebe BASE (Basically Available, Soft-State und Eventual Consitency). Das DBMS ist immer verfügbar (zumindest nimmt es immer Schreib-Aktionen entgegen und liefert bei Anfrage immer ein/irgendein Ergebnis), es hat verschiedenste Zustände und der Datentopf ist fast immer konsistent. Oder in anderen Worten: Verfügbarkeit und Skalierung ist wichtig als Konsistenz. Geopfert werden neben komplexen Funktionen der Commit-Flaschenhals.

Profis fragen sich nun wohl, was mit Update-Konflikten passiert? Ansatz eins: Ausweichen (es gibt verschiedenen Zustände, „ conflicts as a common state, not an exceptional one “) und Ansatz zwei: So simpel lösen, so das es dezental getan werden kann z.B: Last Wins. Schön erklärt ist dies beispielsweise in der Beschreibung von Couch DB: „CouchDB allows for any number of conflicting documents to exist simultaneously in the database, with each database instance deterministically deciding which document is the “winner” and which are conflicts“.
Bevor ich mich nun noch mehr in der Implementierung verliere die wichtigsten Links zum weiterlesen. Das BASE-Paradigma stammt übrigens auf dem Jahr 1998:
– Lessons from Internet Services: ACID vs. BASE. Dr. Eric A. Brewer
– Eventually Consistent. Werner Vogels
– Dynamo: Amazon’s Highly Available Key-value Store
– Bigtable: A Distributed Storage System for Structured Data
Interessant sind zudem Implementierung wie CouchDB oder Project Cassandra.
PS: Die anderen 9 Trends sind: ARIA, Design Driven Development, Rapid Production, Friend-Feeding, Reality Mining, Ubiquitous Access, Touch is the new Click, Rich Browsers und CDN. Einen Eintritt zum Referat am Donnerstag 14. Mai, um 10:30 hätte ich noch zu vergeben.