Was bleibt von NoSQL?

14. Oktober 2013, 13:19

Wenn SQL und ACID wieder salonfähig werden, stellt sich die Frage, was von der NoSQL-Bewegung überbleibt

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)

Markus Winand hat sich als Autor, Trainer und Coach darauf spezialisiert, Entwicklern bei Problemen mit SQL-Performance zu helfen. Er hat das Buch „SQL Performance Explained“ veröffentlicht und spricht auf internationalen Konferenzen.

Links

NoSQL

Homepage von Markus Winand 

Share if you care
Posting 1 bis 25 von 65
1 2

benutze berkley DB schon seit jahren. wenn ich zurückdenken an IMS, das war eine hierarchische datenbank. Und natürlich MUMPS. Ist eine materialized view eigentlich nicht ein map/reduce? Hab irgendwie von dem ganzen inszenierten krieg nix mitbekommen.

früher hat man am begin seiner logic ein begin transaction gemacht und zum schluss ein commit, egal ob IMS, SQL... dann noch ein paar nächtliche jobs mit der eigentlichen logic. das batch fenster zwischen 18:00 - 06:00 verschwindet bzw. ist zu kurz... Zusehends muss logic kontinuierlich asyncron während des tages ausgeführt werden. Minutenlanges table locken geht da nicht mehr...
ACID lebt, SQL lebt, hohe IsolationLevel sterben (leider).

Das Ergebnis ist eine schrittweise Verarbeitung einzelner Datensätze durch die Anwendung.

Erst letzte Woche:
Eine Funktion, die Daten in einer Loop aus der Datenbank rausfischt und einzeln verarbeitet. Dauer der Funktion: ~ 3 min
Ich hab es optimiert und es nur in ein einzelnes SQL-Statement geschrieben. Dauer der Funktion: ~0,5 s

Ist es nicht. Schon mal von Map/Reduce gehört?
Hab auch schon gesehen dass sowas bei Relationalen Datenbanken programmiert wurde.
Wenn man von einer Technologie keine Ahnung hat (bzw unerfahren ist) schreibt man schon mal solchen Schrottcode.

Wollten Sie jemand anderem antworten?
Ich versteh den Zusammenhang zu meinem Posting nämlich nicht ;)

"Das Ergebnis ist eine schrittweise Verarbeitung einzelner Datensätze durch die Anwendung.
Eine Funktion, die Daten in einer Loop aus der Datenbank rausfischt und einzeln verarbeitet. Dauer der Funktion: ~ 3 min "

Ich dachte du meinst dass wäre das Resultat wenn man NoSql DBs verwendet

Nein, das ist das Resultat schlechter Programmierung, egal welche Programmiersprache(in diesem Fall war es eine Stored Procedure unter MySQL) ;)

Jetzt versteh ich es, war ein Zitat aus dem Artikel, muss ich wohl überlesen haben.

Dann hab ich es mißverstanden, Sorry

SQL hat sich bewährt...

Ich arbeite seit ca. 20 Jahren mit RDBMS mit großen Datenmengen(128TB und >). Für mich hat es mit SQL nur dann Probleme gegeben, wenn die User es nicht vollständig beherrschten. Denn anhand der Formulierungsmöglichkeiten bei SQL ist man natürlich schnell beim "it works" und beläßt es dabei ohne das "it works fast" weiter zu verfolgen.
Das geschieht aus geringer Kenntnis von SQL, aus den unangenehmen ACID Vorgaben des RDBMS und dem Gefühl SQL führe einen. Das ist aber nicht der Fall: SQL ist für mich zur komplettesten Sprache in der DB-Landschaft geworden - und auch geografische Daten sind damit durchaus zu eruieren - auch wenn's mit Zusatztools zugegeben leichter geht....SQL ist außerdem mit der Konsistenz der Daten und ACID eng verbunden.

Wobei man schon sagen muss, dass noch bis vor ein paar Jahren SQL gerne Performanceprobleme hatte bei gewissen Abfragekonstellationen und es dann extrem aufwändig war diese zu beseitigen bzw. mittels der limitierten Steuerungsmöglichkeiten zu umgehen. Aber das hat sich inzwischen extrem verbessert und das mach SQL klar zur ersten Wahl.

Super Artikel! Bitte mehr davon!

Toller Artikel

Ein nach wie vor ungelöstes Problem ist mMn die Replikation von Daten der Datenbank auf einen Browser, sodass eine Webapp offlinefähig wird.

Hier versuche ich mit node und pouchdb-server am Server sowie pouchdb und indexedb am Client eine Lösung zu finden.

Ja, das ist sicherlich ein Randthema, aber es könnte wichtig werden, falls noch mehr Browser indexeddb unnterstützen. Support für SQL DBs im Browser scheint ja eher abzunehmen...

NoSQL bedient einfach die Standardszenarien nicht so gut wie SQL. Jetzt war einfach der Hype wo viel mit NoSQL gemacht wurde wo eine SQL Datenbank genauso gut bzw. sogar besser performt hätte.
Ich kombiniere beide sehr gerne.

Bitte mehrere solcher Artikel!
Danke!

ACID

war zumindest bei mir nie out ;)

Kein Ersatz, dafür ein Zusatz

Großartiger Artikel! Ich muss allerdings sagen, dass ich dem letzten Absatz nicht wirklich zustimmen kann.

Ich kenne keinen NoSQL-Datenbank-Hersteller, der sein Produkt als Ersatz zu SQL sieht. MongoDB, CouchDB, Neo4J und Co. sollten vielmehr als SQL-Komplement verstanden werden.

Dokumentdatenbanken machen sich zum Beispiel großartig als Caching-Schicht. Graph-Datenbanken sind die erste Wahl für Abbildungen von Freunden in sozialen Netzwerken.

Wer mit NoSQL SQL aus dem Fenster werfen möchte, ist auf dem falschen Weg. Wer damit aber einfach ein neues Werkzeug in seine Sammlung aufnimmt, macht es richtig.

Ich bin baff...

Einen IT-lastigen Artikel in dieser Qualität habe ich schon lange nicht mehr gelesen.
... und außerdem musste ich richtig lachen bei: " Es scheint fast so, als fuße der Erfolg von NoSQL auch darauf, dass es ein Problem löst, das jeder gerne hätte."
Es ist aber auch keine neue Entwicklung mehr, dass mittlerweile viele Produkte in Marketingabteilungen "designed" werden. Zum Teil "gottseidank", oft aber auch "leider" ;)

NoSQL = NoSkill

Programmierer, die SQL nicht begriffen haben, fanden den NoSQL Müll toll, weil sie "webscale" sind - was auch immer das bedeuten mag.

Auf die Dauer hat sich aber herausgestellt, dass die Konsistenz der Daten doch wichtiger ist und die Vollkoffer, die nichtmal SQL können waren ihre Jobs los.

Ende der Geschichte.

SQL ist eine Interpretersprache. Da kannst du es wenden wie du es möchtest ... einmal SQL immer SQL.

naja

soooo viel Skills braucht man aber für eine SQL DB auch nicht (und außerdem haben die meisten ja schon bald jahrzehnte Erfahrung damit, Tools und Foren gibts auch genug).

Neue Datenbankkonzepte zu erlernen ist jedenfalls spannend und bereichernd - auch wenn es in manchen Fällen ein Irrweg war.

Neben Geld gibt kreative Arbeit sehr viel mehr Motivation. Ohne solche Spielchen wäre die IT ja nur noch öde :)

soooo viel Skills braucht man aber für eine SQL DB auch nich

achja - das sieht man dann, wenn man bei vielen leuten die DB ansieht und dann sieht, daß nichtmal einfachste grundsätze (infos nur 1x abspeichern und nicht bei jedem datensatz) tlw. nicht eingehalten werden.

eine DB z designen braucht nicht viel skill - es gut zu machen aber schon.

Normalisierung ist auch nicht immer sinnvoll

In der Praxis ist ein gewisser Grad an Denormalisierung manchmal gewollt und auch zielführend - weil sonst ab irgendeinem Punkt das Datenmodell sehr komplex wird und bestimmte Queries durch die halbe Datenbank joinen müssen, um alle Daten zu aggregieren.

Da muss man oftmals Tradeoffs zwischen "schönem" Datenbankdesign und Praktikabilität eingehen. Was jetzt aber keine Entschuldigung für schlechtes Datenbankdesign sein soll.

NoSQL-Datenbanken gehen tlw übrigens den anderen Weg und setzen stark auf Denormalisierung, um Queries in einem Schritt aus der Datenbank zu holen. Hat für bestimmte Anwendungsfälle schon Sinn, auch wenn ich dafür (günstigen) Speicherplatz opfere und mir einige Gedanken über Update Anomalies machen muss.

"gute Qualität" ist halt so eine Sache. Lassen wir vorerst Vorliebe guten Geschmack oder Konservatismus beiseite:

Der Kunde zahlt doch viel lieber für ein Fotokarussell anstatt für hohe Qualität, die er nicht sieht. Und auch der IT-ler kann langfristig mit bescheidener Qualität oft viel mehr lukrieren! Der Kunde ist ja auch von anderen Geschäftbereichen intensive Wartung gewohnt und bald ist man fix auf der Payrole.

Ich mag gar nicht daran denken, wieviel 1000 Euro mir wegen vorausschaundem Design durch die Lappen gegangen sind. Lob oder Bonus für reibungslose Funktion gibt es nicht.

Andererseits sind Projekte oft so kurzlebig, dass die Codequalität gar nicht relevant ist.

Jedenfalls sind noSQL ein Spaß und bei Sparse Data unerläßlich.

Andererseits sind Projekte oft so kurzlebig, dass die Codequalität gar nicht relevant ist.

Da liegt meiner Meinung nach aber der große Unterschied zwischen Datenbank-Design und Code.
Code kann ich immer wegschmeißen und neu schreiben. Ein Datenbank-Design zu ändern ohne die bestehenden Daten zu verlieren ist schon eine größere Herausforderung. Deswegen ist es in meinen Augen einer der größten Fehler von Software-Firmen zu wenig über das Datenbank-Design nachzudenken und damit Probleme die sich jahrelang auswirken in Kauf zu nehmen.

Das ist generell ein Problem von IT-Projekten. Niemand plant und keiner will testen.

Posting 1 bis 25 von 65
1 2

Die Kommentare von Usern und Userinnen geben nicht notwendigerweise die Meinung der Redaktion wieder. Die Redaktion behält sich vor, Kommentare, welche straf- oder zivilrechtliche Normen verletzen, den guten Sitten widersprechen oder sonst dem Ansehen des Mediums zuwiderlaufen (siehe ausführliche Forenregeln), zu entfernen. Der/Die Benutzer/in kann diesfalls keine Ansprüche stellen. Weiters behält sich die derStandard.at GmbH vor, Schadenersatzansprüche geltend zu machen und strafrechtlich relevante Tatbestände zur Anzeige zu bringen.