NoSQL ist ein Begriff, der sich in unseren täglichen Sprachgebrauch eingeschlichen hat. Oder vielleicht war es gar kein Schleichen, sondern eher ein Knall, als Johan Oskarsson (Twitter, Apache Software Foundation) 2009 den Begriff für ein Treffen über verteilte strukturierte Datenspeicher (wieder) einführte. Es schien wie eine Erleuchtung, ein Befreiungsschlag gegen die damals immer noch vorherrschende Ideologie, relationale Datenbanken seinen für jeden Problemfall der Weisheit letzter Schluss. Es war immer noch die Zeit, in denen die Oracles und SAPs dieser Welt jede Information für die Maschine in kleinsten Häppchen von Menschenhand verfüttern wollten.
© Bernd Vonau / photocase.de
Währenddessen waren Wikis, Blogs, und Social Networks längst davon abgekommen, jede Information semantisch in Atome zerteilt zu speichern und legten wieder mehr Gewicht auf Verlinkung (man könnte auch Vernetzung und Teilen von Information). Das bewies, dass es eine ganze Menge mehr oder weniger unstrukturierter oder semistrukturierter Daten gibt, die es wert sind gespeichert und verlinkt zu werden.
Der Name ist alles andere als unproblematisch, immer wieder wird NoSQL mit “Nicht SQL” übersetzt. Griff ins K… Bei Oskarsson stand die Abkürzung für “Not only SQL”.
Warum eigentlich NoSQL? Der “Befreiungsschlag” von der reinen SQL-Welt beinhaltete eine simple Erkenntnis: es gibt viele verschiedene Anwendungsfälle und Datenstrukturen, jede ist es wert, eine Speicher-, Verwaltungs- und Abfragemaschine für den Einsatzzweck zu entwerfen. Hier einige Beispiele:
- Graph-Datenbanken (Neo4J): Daten über soziale Beziehungen
- Dokmentenorientierte Datenbanken (MongoDB): Unstrukturierte oder semistrukturierte (markup) Dokumente
- Key/Value Stores (Redis, Memcached, Riak, Couchbase): Messwerte
- Spaltenorientierte Datenbanken (BigTable, Cassandra, HBase, Hypertable): Datenanalyse, überall wo “joinless” zweidimensionale Abfragen eine Rolle spielen
- Objektorientierte Datenbanken (OrientDB)
- Zeitreihendatenbanken (InfluxDB): Messdaten, IoT
Das heißt, der Begriff NoSQL lädt nicht nur zu einer falschen Verwendung ein, er beschreibt ganz verschiedene Klassen von Datenbanken. Er vernebelt damit den Blick auf das Wesentliche.
In meiner täglichen Praxis erkläre ich oft, warum in bestimmten Anwendungsfällen bestimmte Datenbanken den Anforderungen eher gerechter werden als andere. Und gerade Entwickler sollten sich davor hüten NoSQL als Lösung für irgendetwas zu verkaufen, denn es ist keine.
Der Nebel durch den Begriff NoSQL wird noch dichter, wenn man sich vor Augen führt das SQL zunächst einmal nur die “Structured Query Language” ist, also die Abfragesprache mit der die Datenbanken abgefragt werden. Wenn wir heute die MongoDB, InfluxDB oder andere sogenannte “NoSQL” Datenbanken ansehen, dann wird dort inzwischen versucht, SQL ähnliche Abfragesprachen zu konstruieren. Was ist dann eigentlich gemeint? Eigentlich müsste der Begriff No-Relational heißen, also alle Datenbanken, die nicht auf relationalen Datenstrukturen basieren.
Und wie erklärt man nun Vor- und Nachteile relationaler Datenstrukturen? Am besten gar nicht. Tatsächlich sind die Vorzüge der sogenannten “NoSQL Lösungen” gar nicht so sehr davon abhängig, welche Datenstrukturen zugrunde liegen, sondern eher von deren Umgang mit dem CAP-Theorem. Denn der ermöglicht es, an den Stellschrauben der Skalierbarkeit zu drehen: mehr Verfügbarkeit, mehr Konsistenz oder mehr Partitionierbarkeit.
Ein weiterer, oft fälschlicherweise rein den NoSQL Datenbanken zugeschriebener Vorteil ist die Verarbeitung der Daten im Hauptspeicher und der sich daraus ergebende Geschwindigkeitsvorteil. Gerade relationale Datenbanken haben zwei Jahrzente Optimierungen hinter sich und versuchen, durch verschiedene Techniken den Zugriff auf langsame Speicher wenn möglich zu verhindern (Stichworte wären hier z.B. Query, Index Caching, Temprary Tables, Join Caches). Das Datenbanken gar keine Persistenz mitbringen (beispielsweise memcached), zwingt den Entwickler dazu, diese Datenbank nur im RAM zu nutzen, entbindet ihn meist aber nicht vor der Aufgabe, die Daten irgendwo zu persistieren. Und da kommt dann zum Beispiel doch oft wieder PostgreSQL oder MySql zum Einsatz.
Am Ende bleiben 4 wesentliche Kriterien:
- Wie gut passen die Datenstrukturen der Datenbank zu den Datenstrukturen der Anwendung/Domäne?
- Wie gut passt die Abfragesprache zum Anwendungsfall?
- Wie gut skaliert die Lösung für die konkrete Anwendung?
- Wie hoch sind die Ausfallsicherheit und Daten-Konsistenz der Lösung?
Und, last but not least, geht es darum, wie viel Operations-Aufwand die Lösung mit sich bringt. Aber hier ist die Frage keine Klassenfrage, sondern nur ein Implementierungsdetail der jeweiligen Datenbank.
Sehr erfrischend und angenehm ist ebenfalls ein etwas neuer Trend: die Datenbanksysteme konvergieren und die Ideologien brechen. Beispielsweise hat PostgresSQL frühzeitig mit ihrem JSON/hstore angefangen und MariaDB ermöglicht es nun mit Dynamic Column Databse oder ihrer Cassandra Storage Engine, sinnvolle Techniken aus dem Bereich der sogenannten NoSQL Datenbanken in Ihre Produkte zu übernehmen.
Also: lasst uns in Zukunft das jeweilige Kind bei seinem Namen nennen!