SQL kennt in Developer- Kreisen so ziemlich jeder. Das relationale Datenbankschema mit der dazugehörigen Sprache ist die meist genutzte Methode, um Daten permanent abzuspeichern. Die beliebtesten OpenSource Vertreter sind MySQL, PostgreSQL und SQLite.

Obwohl der Begriff NoSQL („Not only SQL“) schon seit den 1960ern existiert ist diese Variante der Datenspeicherung erst seit 2009 ein gängiger Begriff in der Developer- Szene. Hierbei handelt es sich um einen Überbegriff der die Vielzahl an nicht relationalen, verteilten Datenspeichersystemen beschreibt. Die bekanntesten „NoSQL Datenbanken“ sind MongoDB, CouchDB, Redis und Apache Cassandra. Das Battle zwischen SQL und NoSQL Datenschemata hat in Europa bzw. speziell in Österreich aber erst in den letzten Jahren Einzug gehalten.

Inzwischen unterscheiden sich die Meinungen über die beiden Methoden schon stark. Die einen halten an der „alten“ SQL-Methode fest, die anderen schwören auf die „neue“ NoSQL-Methode Zugegebenermaßen kann man dieses Thema je nach Vorliebe für das jeweilige Schema betrachten. Ich möchte hier nicht eine der beiden Methoden favorisieren oder gar besser da stehen lassen. Mein Ziel für diesen Artikel ist es, einen sachlichen Vergleich zwischen SQL und NoSQL Datenbanken zu liefern. Die Effektivität und vor allem auch der Umgang ändern sich schließlich auch je nach Anwendungsfall.

SQL Tabellen vs. NoSQL Dokumente

SQL Datenbanken verwenden zum Speichern von Daten Tabellen. Diese haben festgelegte Attribute. Jede Zeile in einer Tabelle entspricht einem Datensatz. Eine Tabelle kann also nur eine Art von Information speichern. Es würde nicht funktionieren in einer Tabelle BUCH mit den Attributen ISBN, Titel, Autor, Jahr einen Datensatz AUTOR mit den Attributen Name, Geburtsjahr, Herkunft, bevorzugtes Genre zu speichern. Im Gegensatz zu den Tabellen in SQL werden Daten in NoSQL als JSON-ähnliche Key-Value Paare in einer Datei gespeichert. Ähnliche Dokumente können in einer „Collection“ gespeichert werden (analog zu SQL Tabellen). In NoSQL können also beliebige Daten in beliebigen Dokumenten gespeichert werden. Die Tabellen von SQL geben also eine strikte Vorgabe welche und wie Daten gespeichert werden. Dies verhilft zu einer sehr niedrigen Fehlerquote. NoSQL ist hier flexibler, dies kann aber zu Problemen in der Konsistenz führen.

SQL Schemata vs. NoSQL schemalos

Wie schon erwähnt werden die Daten in SQL mittels Tabellen gespeichert. Gibt es noch kein Tabellen Grundgerüst mit den einzelnen Attributen (was das sogenannte Schema ergibt), können auch noch keine Daten gespeichert werden. In NoSQL können Daten immer und überall gespeichert werden. Es muss kein Dokument, oder keine Vorgabe wie die Daten gespeichert werden sollen existieren – die Daten werden einfach gespeichert. Als Beispiel wird hier ein neues Dokument mittels MongoDB gespeichert und zur BUCH Collection hinzugefügt:

db.book.insert(
     ISBN: 234567890,
     title: „Dies ist ein Buch“,
     author: „Max Mustermann“,
     year: 2016
);

MongoDB erstellt automatisch für jedes Dokument in einer Collection ein eindeutiges _id Attribut.

Eine NoSQL Datenbank macht also Sinn, wenn Daten und Anforderungen anfangs nur schwer definiert werden können. Achtung: Einfachheit nicht mit Faulheit verwechseln: das nichtvorhandensein einer Struktur der zu speichernden Daten kann später zum Problem werden.

SQL Normalisierung vs. NoSQL Denormalisierung

In SQL wird für eine Beziehung für die vorher beschriebene BUCH Tabelle und einer HERAUSGEBER Tabelle in der BUCH Tabelle ein Attribut HERAUSGEBER_ID hinzugefügt. Dies minimiert die Redundanz von Daten – ein Herausgeber existiert also nur in der HERAUSGEBER Tabelle, als Referenz wird nur die eindeutige ID in der BUCH Tabelle hinzugefügt. Dies nennt sich Normalisieren. In NOSQL ist dies zwar auch ohne weiteres möglich, aber nicht immer praktisch. Also wird NoSQL denormalisiert abgespeichert. Für das obige Beispiel heißt das, dass der Herausgeber zu jedem Buch dazugespeichert wird. Die Herausgeber Tabelle fällt somit weg. Die wird unter anderem deshalb gemacht, damit Queries (also Abfragen auf die Daten) schneller sind. Bei SQL muss hierfür ein Join über die jeweiligen Tabellen gemacht werden um zum Beispiel alle Bücher von einem Herausgeber X zu bekommen. In NoSQL gibt es aufgrund des Denormalisierens keine Joins. Der Herausgeber steht direkt im Buch. Somit muss nichts verknüpft werden und die Abfrage kann direkt auf die Bücher erfolgen.
Das Updaten eines einzelnen Datenrecords ist allerdings bei dieser Variante viel langsamer da ein und derselbe Herausgeber in allen Bücher-Datensätzen in denen er vorkommt geändert werden muss.

SQL vs. NoSQL Scaling

Bei großen Datenmengen stellt sich die Frage ob die Anfragen nicht auf mehrere Server aufgeteilt werden sollten. Wird SQL verwendet, ist diese eher kompliziert. Wie soll die Zuteilung erfolgen? Eine mögliche Lösung wäre Clustering. Aber auch dies ist sehr komplex. NoSQL macht es einem in dieser Hinsicht einfacher. Einige NoSQL Modelle haben von Haus aus schon Scaling Funktionalitäten eingebaut.

Freilich gibt es noch viele weitere Unterschiede zwischen den beiden Methoden SQL und NoSQL. Mein Ziel ist es aber die meiner Meinung nach ausschlaggebendsten aufzuzeigen. Also Fazit lässt sich noch eine Zusammenfassung erstellen welche der beiden Methoden für welche Art von Projekten praktikabler ist:

Projekte für die SQL ideal ist:

• Logisch ähnliche diskrete Datenanforderungen die im Vorhinein identifiziert werden können
• Wenn Datenintegrität wichtig ist
• Wenn standard-basierte bewährte Technologien mit gutem Support verwendet werden sollen

Projekte für die NoSQL ideal ist:

• Datenanforderungen sind noch nicht klar
• Einfache/lockerere Projektziele; Möglichkeit sofort mit der Programmierung zu starten
• Geschwindigkeit und Skalierbarkeit ist zwingend erforderlich