NoSQL still matters

Vom 28. April bis zum 30. April fand die NoSQL matters in Köln statt. Austragungsort war das KOMED im MediaPark, nur knapp 15 Gehminuten von Kölner Hauptbahnhof und Dom entfernt. Neben zwei Tagen mit Vorträgen gab es auch einen Trainingstag. Die angebotenen Workshops waren hochwertig, und einige Firmen wie Neotechnology haben die Chance genutzt um neben der Konferenz auch ein Meetup durchzuführen. Die Vorträge auf der Tagung waren breit gestreut, und aufgrund der noch überschaubaren Teilnehmerzahl gab es viel Gelegenheit für Diskussion. Die Teilnahme an diesen Veranstaltungen kann ich uneingeschränkt all denjenigen empfehlen, die sich für neue Datenbanktechnologien und BigData interessieren, und einen Einblick aus sowohl anwendungsorientierter als auch theoretisch fundierter Sicht gewinnen wollen. Inhalt dieses kurzen BlogPosts sollen jedoch ein paar Punkte sein, an denen sich die Geister noch immer scheiden, und die auch auf der Konferenz in Köln immer wieder zu Diskussionen geführt haben.
Was gehört zu NoSQL?
NoSQL ist eine noch junge und damit beständigem Wandel und der Suche nach Definitionen unterworfene Disziplin der Informatik. Wie so oft trifft man hier oft auf altbekannte Konzepte in neuem Gewand. Es besteht nach wie vor keine einheitliche Meinung, was unter dem Begriff NoSQL genau zu verstehen ist. Einigkeit herrscht mittlerweile in der Klassifikation der Datastores in vier Kategorien: Key/Value Stores, Document Stores, Wide Column Stores und Graphdatenbanken. Darüber hinaus werden viele Schlagworte und deren Zugehörigkeit zu NoSQL kontrovers diskutiert und je nach Anwendungskontext auch unterschiedlich interpretiert: CAP, BASE, ACID, Datenredundanz, horizontale und vertikale Skalierung, Normalisierung und Denormalisierung, Sharding und Replikation, und viele mehr.
Diskussionen über die folgenden drei Punkte sind mir in Köln wiederholt aufgefallen, die mir nicht immer gut und einheitlich verstanden schienen.
Namensgebung relationaler Datenbanksysteme
Relational sind relationale Datenbanksysteme, weil sie ihren Ursprung in den mathematischen Relationen haben.Relationen meinen nicht die Beziehungen zwischen den Tupeln der Datenbanktabellen, sondern bezeichnen Mengen von Tupeln. Formal ist eine Relation nichts weiter als eine benannte Teilmenge des kartesischen Produktes nicht-leerer Mengen, und deren Elemente sind Tupel. Die relationale Algebra, bzw. äquivalente Kalküle wie der TRC oder DRC, sind die Grundlage für relationale Anfragesprachen (und damit letztlich auch für SQL). Dieser Relationsbegriff hat erst einmal nichts zu tun mit referentieller Integrität, d.h. der inneren Konsistenz der in einer relationalen Datenbank gespeicherten Tupel.
Konsistenz: Das C in ACID und CAP
Der Buchstabe C in den Akronymen ACID und CAP steht beide Male für Konsistenz (engl. Consistency), meint aber jeweils einen anderen Konsistenzbegriff. Die Konsistenz in ACID bedeutet, dass nur Übergänge von gültigen Zuständen in gültige Zustände erlaubt sind, und zwar im Sinne der für die Datenbank definierten referentiellen Integrität. Dies meint also eine ‘innere Konsistenz’ der in einer Datenbank gespeicherten Tupel. Konsistenz im Sinne von CAP bedeutet, dass jeder Knoten im verteilten System zu jedem Zeitpunkt die ‘richtige’ Antwort zu jeder Anfrage liefert. Die Anforderung an die Konsistenz hängt damit vom Service ab. Der vielleicht natürlichste Konsistenzbegriff ist der der linearisierbaren Konsistenz: Dies bedeutet, das jeder Client, der Anfragen an das verteilte System stellt, den Eindruck hat, das alle Request/Response-Operationen von einem einzigen, zentralen Server beantwortet werden. (Formal heißt das, dass eine totale Ordnung dieser Operationen existieren muss, so das jede Operation als sofort und exklusiv ausgeführt erscheint.)
Vielleicht konsistente Systeme?
In der NoSQL Welt wird häufig der Begriff der eventual consistency angetroffen (u.a. als Bestandteil des Akronyms BASE: Basically Available, Soft state, Eventual consistency). Das englische Wort eventual ist nicht mit dem deutschen Wort eventuell zu übersetzen, sondern eher mit schlussendlich! Eventual consistency ist ein Konsistenzmodel für verteilte Systeme: Ein verteiltes System erfüllt dieses Modell, wenn es für ein gespeichertes Datum, vorausgesetzt das keine Updates mehr für dieses erfolgen, irgendwann für alle Anfragen nach diesem Datum den selben, zuletzt aktualisierten Wert liefert. Eventual consistency bedeutet nicht, dass das System ‘vielleicht mal’ einen konsistenten Zustand erreicht.
Diskussion

Durch die zunehmende Zahl an verfügbaren Datastores und deren Spezialisierung wird es auch zunehmend wichtiger, genau zu wissen, für welchen Anwendungsbereich und Use-Case ein Datastore gewählt werden soll. Davon hängt ab, welches Konsistenzmodell zur Anwendung kommen soll, welches Datenmodell sich anbietet und wie Sharding- und Replikationsstrategien zu wählen sind. Insbesondere dann, wenn auch polyglotte Lösungen zum Einsatz kommen sollen. Die teilweise noch vorhandenen unterschiedlichen Auffassungen der Definitionen und die resultierenden Missverständnisse machen die Diskussionen im Bereich NoSQL nach wie vor spannend, zumal umfassende Langzeiterfahrungen aufgrund des Alters dieser Technologien noch nicht vorliegen können. Kommentare und Meinungen hierzu sind ausdrücklich erwünscht!

Ausgewählte Literatur
Es gibt eine Vielzahl lesenswerter Artikel und Bücher zu den oben diskutierten Themen. Eine nützliche (wenn auch subjektive) Auswahl findet sich nachstehend. Auch die in diesem Blog geäußerten Gedanken und Ausführungen folgen teilweise diese Büchern und Artikeln.

• Seth Gilbert and Nancy Lynch. Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services. SIGACT News, vol. 33, no. 2, pp. 51-59, 2002
• Stefan Edlich, Achim Friedland, Jens Hampe, Benjamin Brauer und Markus Brückner. NoSQL: Einstieg in die Welt nichtrelationaler Web 2.0 Datenbanken. Hanser Verlag. 2011
• Eric Brewer, “CAP Twelve Years Later: How the “Rules” Have Changed,” Computer, vol. 45, no. 2, pp. 23-29, 2012
• Seth Gilbert and Nancy A. Lynch. Perspectives on the CAP Theorem. Computer, vol. 45, no. 2, pp. 30-36, 2012
• Pramod J. Sadalage and Martin Fowler. NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence. Addison-Wesley Professional. 2012
• Eric Redmond and Jim R. Wilson. Seven Databases in Seven Weeks. Pragmatic Bookshelf. 2012
• Katarina Grolinger, Wilson A Higashino, Abhinav Tiwari, and Miriam AM Capretz.  Data management in cloud environments: NoSQL and NewSQL data stores. Journal of Cloud Computing: Advances, Systems and Applications, vol. 2, no. 22, 2013