Google setzt also wieder verstärkt auf SQL, berichtet "The Register". Das mag auf den ersten Blick überraschend erscheinen, hat doch ausgerechnet der Internet-Gigant der NoSQL-Bewegung durch seine Veröffentlichungen über MapReduce und BigTable gehörigen Auftrieb verschafft. Beim genaueren Hinsehen stellt sich aber heraus, dass es den Trend, mittels SQL oder ähnlicher Sprachen auf NoSQL Datenquellen zuzugreifen, schon länger gibt. Stellt sich nur die Frage: Was bleibt von NoSQL, wenn man SQL wieder hinzufügt? Um dieser Frage nachzugehen, rollen wir die Geschichte der Datenbanken kurz auf.

Platzhirsch SQL

Bis vor wenigen Jahren war es unumstritten: Zum Speichern von Unternehmensdaten verwendet man relationale Datenbanken, auf die man mit der Abfragesprache SQL zugreift.

Die theoretischen Grundlagen für das relationale Modell wurden schon 1970 gelegt. Der erste kommerzielle Vertreter des neuen Datenbank-Typus war bereits 1979 mit rudimentärer SQL-Unterstützung verfügbar: die Oracle-Datenbank in der Version 2. Das heutige Erscheinungsbild relationaler Datenbanken wurde dann in den 1980er Jahren geprägt. Maßgeblich waren hierbei die Formulierung der ACID-Eigenschaften (Atomicity, Consistency, Isolation, Durability), die versehentliche Daten-Korruption verhindern, und die Standardisierung der Abfragesprache SQL—zuerst durch ANSI und ein Jahr später durch ISO. Fortan waren SQL- und ACID-Konformität erstrebenswerte Ziele für Datenbankhersteller.

In den darauf folgenden Jahrzehnten hat sich oberflächlich betrachtet nicht viel getan—das führte wohl auch dazu, dass SQL und das rationale Modell manchmal als alte – oder gar veraltete – Technologien bezeichnet werden. Genauer betrachtet entwickelten sich SQL-Datenbanken in dieser Zeit aber zu ausgereiften Produkten. Diese lange Reifephase war nötig, weil SQL als deklarative Sprache den Möglichkeiten der 1980er Jahre weit voraus war. Ein SQL-Entwickler definiert nämlich nicht die Abfolge der Schritte die zum Ergebnis führen, sondern nur wie das Ergebnis letztendlich aussehen soll. Die Datenbank ermittelt den besten Weg dorthin automatisch—was keineswegs trivial ist und die frühen SQL-Datenbanken nur bei einfachen Abfragen ausreichend gut beherrschten. Über die Zeit wurde die Hardware leistungsfähiger und die Datenbank-Software ausgereifter, sodass heutige Datenbanken auch bei sehr komplexen Abfragen gute Ergebnisse liefern—bis hin zu Business Intelligence Auswertungen.

Zweifelsohne war die Möglichkeit, Daten mit den Bordmitteln einer SQL-Datenbank einfach und schnell aufzubereiten, ein entscheidender Faktor, der dazu beitrug, dass SQL und das relationale Modell die erste Wahl in Sachen Datenbanken wurden.

Und dann: NoSQL

Trotz der Omnipräsenz von SQL konnte sich in den vergangen Jahren ein neuer Trend etablieren: NoSQL. Dieser Begriff hat den Nerv vieler Entwickler getroffen und eine Dynamik entwickelt, die zu einem regelrechten Glaubenskrieg führte. Die Kontrahenten waren SQL als Sinnbild für veraltete, langsame und teure Technologie gegen eine nicht näher bestimmbare Sammlung neuer und hoch-skalierbarer Gratis-Software, die nicht viel mehr als die Dachmarke „NoSQL" vereint.

Diese Ablehnung gegenüber SQL kann unter anderem damit erklärt werden, dass der zunehmende Einsatz objektrelationaler Werkzeuge dazu führt, dass Entwickler Datenbanken nur noch als reines Speichermedium betrachten („persistence layer"). Die Nutzung von SQL zur Neukombination und Aufbereitung der Daten wird nicht gefördert, sondern erheblich erschwert. Das Ergebnis ist eine schrittweise Verarbeitung einzelner Datensätze durch die Anwendung. Unter diesen Voraussetzungen bietet SQL tatsächlich keinen Mehrwert und man kann die Sympathie, die Entwickler dem Begriff NoSQL entgegenbringen, durchaus nachvollziehen.

Das Problem dabei ist, dass der Begriff NoSQL keineswegs gegen SQL gerichtet ist. Um das klarzustellen, wurde dem Begriff nachträglich die Bedeutung „not only SQL" zugewiesen. Es geht vielmehr um Alternativen—um genau zu sein, noch nicht einmal um Alternativen zu SQL, sondern zum relationalen Modell und vor allem zu ACID. In der Zwischenzeit hatte sich durch das CAP-Theorem nämlich herausgestellt, dass die Erfüllung der ACID-Eigenschaften bei verteilten Datenbanken zwangsläufig zu einer Reduktion der Verfügbarkeit führt. Dadurch können traditionelle Datenbanken die Ressourcen von Cloud-Umgebungen nicht unbeschränkt nutzen. Und genau dafür bietet NoSQL eine Lösung: Anstatt die strikte Einhaltung der ACID-Kriterien zu forcieren, nimmt man mangelhafte Daten bewusst in Kauf, um stattdessen die Verfügbarkeit in einer verteilten Umgebung zu gewährleisten. Anders gesagt liefert man im Zweifelsfall lieber falsche (alte) Daten, als gar keine. Die korrekte—aber kaum Zugkräftige—Bezeichnung dieses Trends wäre also NoACID.

Der Einsatz sogenannter NoSQL-Systeme macht also nur bei Anwendungen Sinn, die keine strikte Daten-Konsistenz erfordern. Das sind häufig Anwendungen im Bereich Sozialer-Netzwerke, die ihren Zweck im Zweifelsfall auch mit alten Daten erfüllen können, und bei denen der Verlust einzelner Updates verkraftbar ist. Das sind gleichzeitig auch Anwendungen, die die theoretisch unbeschränkte Skalierbarkeit einer Cloud-Umgebung potenziell benötigen könnten. Findet man hingegen mit einer zentralisierten Datenbank das Auslangen, gibt es laut CAP-Theorem keinen zwingenden Grund auf die von ACID gebotene Sicherheit zu verzichten. Der Einsatz eines NoSQL-Systems kann aber auch Sinn machen, wenn die Aufbereitung der Anwendungsdaten mit SQL schwierig ist. Auch das ist ein Problem, das im Bereich Sozialer-Netzwerke verstärkt auftritt: Die Verbindungen zwischen Personen lassen sich in einem relationalen Modell zwar gut darstellen, die Analyse mittels SQL kann im besten Fall aber als mühsam bezeichnet werden.

Dennoch: zurück zu SQL

Dennoch kann man mit SQL unzählige Fragestellungen einfach und schnell beantworten. Das sind insbesondere auch Fragestellungen, die man zum Zeitpunkt des Anwendungsdesigns noch nicht absehen konnte. Nachdem NoSQL-Systeme nun seit einigen Jahren im Einsatz sind, stehen sie nun auch vor dieser Herausforderung. Der Ruf nach Abfragesprachen wie SQL wird immer lauter.

Ein anderer Aspekt, der den aktuellen Trend zurück zu SQL stärkt, geht an den Kern von NoSQL: Ohne ACID ist es sehr schwierig zuverlässige Software zu entwickeln. Google sagt das in der aktuellen Veröffentlichung zur SQL-Datenbank F1 ganz klar: ohne ACID verwenden Entwickler einen signifikanten Teil ihrer Zeit darauf, sehr komplexe und fehleranfällige Mechanismen zu bauen, um mit Daten umzugehen, die vielleicht veraltet sind. Offenbar lernt man ACID erst richtig zu schätzen, wenn man versucht, ohne auszukommen.

Was bleibt von NoSQL?

Wenn SQL und ACID wieder salonfähig werden, stellt sich die Frage, was von der NoSQL-Bewegung überbleibt? Wurde dadurch möglicherweise wirklich eine halbe Dekade vergeudet, wie The Register spekuliert? Was man auf jeden Fall sagen kann, ist, dass SQL- und ACID-Konformität nach wie vor erstrebenswerte Ziele für Datenbankhersteller sind. Weiters weiß man, dass man einen Kompromiss zwischen ACID-Konformität und Cloud-Skalierbarkeit eingehen muss.

Das Rennen um den Heiligen Gral der optimalen Balance zwischen ACID und Skalierbarkeit hat natürlich längst begonnen. Die NoSQL-Systeme rollen das Feld von der Ecke der unbeschränkten Skalierbarkeit her auf, indem sie zunehmend Mechanismen zur besseren Steuerung der Daten-Konsistenz nachliefern. Aber natürlich gibt es auch Newcomer, die unter dem Schlagwort NewSQL völlig neu entwickelte Datenbanken auf den Markt bringen, die von Anfang an eine ACID-konforme SQL-Schnittstelle bieten, intern aber NoSQL-Ansätze verwenden, um die Skalierbarkeit zu verbessern.

Und was machen die etablierten Datenbankanbieter? Natürlich versuchten sie uns durch Produkte wie „Oracle NoSQL Database" oder „Windows Azure Table Storage Service" weiszumachen, dass sie auch „NoSQL können." Diese Produkte sind aber so offensichtlich nur zu Marketing Zwecken geschaffen worden, dass man sich fragen muss, warum nichteinmal NewSQL als Bedrohung wahrgenommen wird. Am Beispiel der Oracle-Datenbank, die mittlerweile in der Version 12c vorliegt, kann man sogar den umgekehrten Trend beobachten. Denn obwohl der Versions-Zusatz „c" die Cloud-Fähigkeit ausdrücken soll, erfüllt das Killer-Feature dieser Version eine ganz andere Anforderung: Den einfachen und sicheren Betrieb mehrere Datenbanken auf einem Server. Das ist das genaue Gegenteil dessen, was NoSQL ermöglicht: eine gigantische Datenbank mit Hilfe einer Unzahl handelsüblicher Server aufzubauen.

Kann es denn tatsächlich sein, dass die etablierten Datenbankhersteller einer derart grundlegenden Fehleinschätzung unterliegen? Oder ist es so, dass die NoSQL-Bewegung nur eine kleine Marktnische bedient? Wie viele Unternehmen haben tatsächlich mit Datenmengen wie Google, Facebook oder Twitter zu kämpfen? Im Übrigen drei Unternehmen, die mit Hilfe der Open-Source-Datenbank MySQL groß wurden. Es scheint fast so, als fuße der Erfolg von NoSQL auch darauf, dass es ein Problem löst, das jeder gerne hätte. Tatsächlich hat dieses Problem offenbar nur eine sehr kleine Community, die dafür umso lauter von sich reden macht. So bleibt NoSQL wohl weiterhin nur ein Sturm im Wasserglas. (Markus Winand, derStandard.at, 14.10. 2013)