NoSQL (englisch für „Not only SQL“, auch als „Non-SQL“ bezeichnet) ist ein Ansatz für das Datenbankdesign, der das Speichern und Abfragen von Daten außerhalb der traditionellen Strukturen relationaler Datenbanken ermöglicht. Es können zwar immer noch Daten gespeichert werden, die sich in relationalen Datenbankmanagementsystemen (RDBMS) befinden, aber sie werden anders gespeichert als in einem RDBMS. Die Entscheidung zugunsten einer relationalen Datenbank und gegen eine nicht relationale Datenbank ist weitgehend vom Kontext abhängig und variiert je nach Anwendungsfall.

Anstelle der typischen tabellarischen Struktur einer relationalen Datenbank enthalten NoSQL-Datenbanken die Daten in einer einzelnen Datenstruktur, z. B. einem JSON-Dokument. Da dieses nicht relationale Datenbankdesign kein Schema erfordert, kann es in kürzester Zeit für das Management großer und typischerweise unstrukturierter Datenmengen skaliert werden.

NoSQL ist auch eine Art von verteilter Datenbank; d. h., dass Informationen kopiert und auf verschiedenen Servern gespeichert werden, die remote oder lokal sein können. Dies stellt die Verfügbarkeit und Zuverlässigkeit der Daten sicher. Ist ein Teil der Daten offline, kann der Rest der Datenbank weiter verwendet werden.  

Unternehmen müssen heute in fast allen Branchen große Datenmengen mit hoher Geschwindigkeit verwalten und schnell skalieren können, um moderne Webanwendungen auszuführen. In einer Zeit, in der Cloud-, Big-Data-, Mobil- und Webanwendungen immer mehr an Bedeutung gewinnen, bieten NoSQL-Datenbanken die erforderliche Geschwindigkeit und Skalierbarkeit und werden aufgrund ihrer Leistung und Benutzerfreundlichkeit gerne eingesetzt. 

NoSQL vs. SQL

Im Zusammenhang mit NoSQL wird häufig auf die strukturierte Abfragesprache (SQL) verwiesen. Um den Unterschied zwischen NoSQL und SQL besser zu verstehen, kann es hilfreich sein, sich mit der Geschichte von SQL zu befassen, einer Programmiersprache, die zum Abrufen bestimmter Informationen aus einer Datenbank verwendet wird.  

Vor den relationalen Datenbanken verwendeten die Unternehmen ein hierarchisches Datenbanksystem mit einer baumartigen Struktur für die Datentabellen. Diese frühen Datenbankmanagementsysteme (DBMS) ermöglichten es den Benutzern, große Datenmengen zu organisieren. Sie waren jedoch sehr komplex, oft an eine bestimmte Anwendung gebunden und nur begrenzt in der Lage, bestimmte Daten aufzufinden. Diese Einschränkungen führten schließlich zur Entwicklung von relationalen Datenbankmanagementsystemen, die Daten in Tabellen anordnen. SQL bot eine Schnittstelle für die Interaktion mit relationalen Daten, sodass Analysten Tabellen durch die Zusammenführung gemeinsamer Felder verbinden konnten.

Im Laufe der Zeit wurde die Forderung nach einer schnelleren und differenzierteren Nutzung großer Datenmengen für neue Technologien, wie z. B. E-Commerce-Anwendungen, immer dringlicher. Die Programmierer brauchten etwas, das flexibler war als SQL-Datenbanken (d. h. relationale Datenbanken). NoSQL war hier die Alternative. 

Während NoSQL eine Alternative zu SQL darstellt, hat diese Weiterentwicklung aber keineswegs die SQL-Datenbanken ersetzt. Angenommen, Sie sind in einem Handelsunternehmen für die Auftragsabwicklung zuständig. In einem relationalen Modell werden die einzelnen Tabellen Kundendaten, Bestelldaten und Produktdaten separat verwaltet und über einen eindeutigen, gemeinsamen Schlüssel, wie z. B. eine Kunden-ID oder eine Bestell-ID, miteinander verbunden. Dies eignet sich zwar hervorragend zum schnellen Speichern und Abrufen von Daten, erfordert jedoch sehr viel Speicher. Wenn Sie mehr Speicher hinzufügen möchten, können SQL-Datenbanken nur vertikal und nicht horizontal skaliert werden; das bedeutet, dass Ihre Möglichkeiten, mehr Speicher hinzuzufügen, auf die vorhandene Hardware beschränkt sind. Dadurch schränkt die vertikale Skalierung letztlich die Datenspeicherung und -abfrage in Ihrem Unternehmen ein.

Im Vergleich dazu sind NoSQL-Datenbanken nicht relational, sodass keine Tabellen mehr verbunden werden müssen.Ihre integrierten Sharding- und Hochverfügbarkeitsfunktionen erleichtern die horizontale Skalierung. Wenn ein einziger Datenbankserver nicht ausreicht, um alle Daten zu speichern oder alle Abfragen zu bearbeiten, kann die Arbeitslast auf zwei oder mehr Server verteilt werden, sodass Unternehmen ihre Daten horizontal skalieren können.

Obwohl jeder Datenbanktyp seine eigenen Vorteile hat, setzen Unternehmen häufig sowohl NoSQL- als auch relationale Datenbanken in einer einzigen Anwendung ein. Die heutigen Cloud-Anbieter können SQL- oder NoSQL-Datenbanken unterstützen. Welche Datenbank Sie wählen, hängt von Ihren Zielen ab. 

Weitere Informationen zu den Unterschieden zwischen den beiden Optionen finden Sie unter „SQL- vs. NoSQL-Datenbanken: Was ist der Unterschied?“

NoSQL bietet weitere Möglichkeiten, Daten auf ganz unterschiedliche Weise zu organisieren. Da NoSQL verschiedene Datenstrukturen bietet, kann es für die Datenanalyse, das Management großer Datenmengen, soziale Netzwerke und die Entwicklung mobiler Anwendungen eingesetzt werden. 

Eine NoSQL-Datenbank verwaltet Informationen unter Verwendung eines dieser primären Datenmodelle:

Schlüssel/Wert-Speicher

Dies wird in der Regel als die einfachste Form von NoSQL-Datenbanken angesehen. Das schemalose Datenmodell ist in einem Wörterbuch mit Schlüssel/Wert-Paaren organisiert, wobei jedes Element einen Schlüssel und einen Wert hat. Der Schlüssel könnte z. B. eine Einkaufswagen-ID in einer SQL-Datenbank sein, während der Wert ein Array von Daten ist, z. B. jedes einzelne Element im Einkaufswagen des Benutzers. Dies wird häufig für das Caching und Speichern von Benutzersitzungsinformationen verwendet, z. B. bei Warenkörben. Es ist jedoch nicht ideal, wenn Sie mehrere Datensätze auf einmal abrufen müssen. Redis und Memcached sind Beispiele für quelloffene Schlüssel/Wert-Datenbanken.

Dokumentspeicher

Wie der Name schon sagt, speichern Dokumentdatenbanken die Daten als Dokumente. Diese Datenbanken sind für die Verwaltung halbstrukturierter Daten geeignet, wobei die Daten in der Regel im JSON-, XML- oder BSON-Format gespeichert werden. Dadurch werden die Daten bei der Verwendung in Anwendungen zusammengehalten und der Übersetzungsaufwand für die Nutzung der Daten wird reduziert. Die Entwickler erhalten auch mehr Flexibilität, da die Datenschemata nicht über alle Dokumente hinweg übereinstimmen müssen (z. B. Name vs. Vorname). Dies kann jedoch bei komplexen Transaktionen problematisch sein und zu fehlerhaften Daten führen. Gängige Anwendungsfälle für Dokumentdatenbanken sind Content-Management-Systeme und Benutzerprofile. Ein Beispiel für eine dokumentorientierte Datenbank ist MongoDB, die Datenbankkomponente des MEAN-Stack.

Möchten Sie mehr über MongoBD erfahren? Sehen Sie sich das IBM Lernprogramm über die ersten Schritte zur Verwendung von IBM Cloud Databases for MongoDB an. 

Wide-Column-Speicher

Diese Datenbanken speichern Informationen in Spalten. Die Benutzer können gezielt auf die benötigten Spalten zugreifen, ohne zusätzlichen Speicher für irrelevante Daten reservieren zu müssen. Diese Datenbank versucht, die Unzulänglichkeiten von Schlüssel/Wert- und Dokumentspeichern auszugleichen. Da die Verwaltung dieses Systems jedoch komplexer sein kann, ist es für neuere Teams und Projekte nicht zu empfehlen. Apache HBase und Apache Cassandra sind Beispiele für quelloffene Wide-Column-Datenbanken. Apache HBase baut auf dem Hadoop Distributed Files System auf, das eine Möglichkeit zur Speicherung von dünn besetzten Datasets bietet, wie sie in vielen Big-Data-Anwendungen verwendet werden. Apache Cassandra hingegen wurde entwickelt, um große Datenmengen auf mehreren Servern und in Clustern zu verwalten, die sich über mehrere Rechenzentren erstrecken. Es wurde bereits für eine Vielzahl von Anwendungsfällen eingesetzt, z. B. für Websites sozialer Netzwerke und Echtzeit-Datenanalytik.

Graphspeicher

Diese Art von Datenbank enthält in der Regel Daten aus einem Wissensdiagramm. Datenelemente werden als Knoten, Kanten und Eigenschaften gespeichert. Jedes Objekt, jeder Ort und jede Person kann ein Knoten sein. Eine Kante definiert die Beziehung zwischen den Knoten. Ein Knoten könnte zum Beispiel ein Kunde wie IBM und eine Agentur wie Ogilvy sein. Eine Kante würde die Beziehung als eine Kundenbeziehung zwischen IBM und Ogilvy kategorisieren.

Graphdatenbanken werden zur Speicherung und Verwaltung eines Netzes von Verbindungen zwischen Elementen innerhalb des Graphen verwendet. Neo4j (Link befindet sich außerhalb von IBM), ein graphenbasierter Datenbankservice auf Java-Basis mit einer Open-Source-Community-Edition, bei der Benutzer Lizenzen für Online-Backup und Hochverfügbarkeitserweiterungen erwerben können, oder eine lizenzierte Vorabversion, die Backup und Erweiterungen enthält. 

In-Memory-Speicher

Bei diesem Datenbanktyp (z. B. IBM solidDB) befinden sich die Daten im Hauptspeicher und nicht auf der Festplatte, wodurch der Datenzugriff schneller erfolgt als bei herkömmlichen, festplattenbasierten Datenbanken. 

Beispiele für NoSQL-Datenbanken

Viele Unternehmen haben sich bereits für eine NoSQL-Lösung entschieden. Neben den bereits genannten sind im Folgenden einige weitere gängige NoSQL-Datenbanken aufgeführt:

• Apache CouchDB, eine quelloffene, auf einem JSON-Dokument basierende Datenbank, die JavaScript als Abfragesprache verwendet. 
• Elasticsearch, eine dokumentbasierte Datenbank, die eine Engine für die Volltextsuche beinhaltet. 
• Couchbase, eine Schlüssel/Wert- und Dokumentdatenbank, die es Entwicklern ermöglicht, reaktionsfähige und flexible Anwendungen für Cloud, Mobile und Edge Computing zu erstellen. 

Weitere Informationen zum Datenbankstatus finden Sie in der „Kurzübersicht des Datenbankumfelds“.

Jeder Typ von NoSQL-Datenbank hat bestimmte Stärken, durch die er für bestimmte Anwendungsfälle besser geeignet ist. Sie haben jedoch alle gemeinsam die folgenden Vorteile für Entwickler und schaffen den Rahmen, um Kunden einen besseren Service zu bieten:

• Kosteneffektivität: Die Wartung von hochwertigen, kommerziellen RDBMS ist teuer. Sie erfordern den Kauf von Lizenzen, geschulte Datenbankmanager und leistungsfähige Hardware für die vertikale Skalierung. NoSQL-Datenbanken ermöglichen eine schnelle horizontale Skalierung und eine bessere Ressourcenzuweisung, um die Kosten zu minimieren. 

• Flexibilität: Horizontale Skalierung und ein flexibles Datenmodell bedeuten auch, dass NoSQL-Datenbanken große Mengen sich schnell ändernder Daten bewältigen können, wodurch sie sich hervorragend für agile Entwicklung, schnelle Iterationen und häufige Code-Pushs eignen. 

• Replikation: NoSQL-Replikationsfunktionen kopieren und speichern Daten über mehrere Server hinweg. Diese Replikation sorgt für die Zuverlässigkeit der Daten, stellt den Zugriff während der Ausfallzeiten sicher und schützt vor Datenverlust, wenn die Server offline gehen. 

• Geschwindigkeit: NoSQL ermöglicht eine schnellere und flexiblere Speicherung und Verarbeitung für alle Benutzer, von Entwicklern über Vertriebsteams bis hin zu Kunden. Aufgrund ihrer Geschwindigkeit eignen sich NoSQL-Datenbanken im Allgemeinen auch besser für moderne, komplexe Webanwendungen, E-Commerce-Sites oder mobile Anwendungen.  

Kurz gesagt: NoSQL-Datenbanken bieten hohe Leistung, Verfügbarkeit und Skalierbarkeit. 

Die Struktur und der Typ der NoSQL-Datenbank, für die Sie sich entscheiden, hängt davon ab, wie Ihr Unternehmen sie nutzen möchte. Im Folgenden finden Sie einige spezifische Verwendungszwecke für verschiedene Arten von NoSQL-Datenbanken. 

• Management von Datenbeziehungen: Das Management der komplexen Datenaggregation und der Beziehungen zwischen diesen Punkten wird in der Regel mit einer graphenbasierten NoSQL-Datenbank durchgeführt. Dazu gehören Recommendation Engines, Wissensgraphen, Anwendungen zur Betrugserkennung und soziale Netzwerke, in denen anhand verschiedener Datentypen Verbindungen zwischen einzelnen Personen hergestellt werden. 

• Leistung mit geringer Latenz: Gaming, Fitnessanwendungen für zu Hause und Werbetechnologie erfordern alle einen hohen Durchsatz für das Datenmanagement in Echtzeit. Diese Infrastruktur bietet den größten Nutzen für den Verbraucher, sei es durch die Aktualisierung von Marktangeboten oder die Anzeige der relevantesten Werbung. Webanwendungen erfordern In-Memory-NoSQL-Datenbanken, um schnelle Reaktionszeiten sicherzustellen und Nutzungsspitzen ohne die Verzögerungen zu bewältigen, die bei Plattenspeichern auftreten können. 

• Skalierung und große Datenvolumen: Der elektronische Handel erfordert die Fähigkeit, große Nutzungsspitzen zu bewältigen, sei es für eine eintägige Verkaufsaktion oder die Weihnachtseinkaufssaison. Schlüssel/Wert-Datenbanken werden häufig in E-Commerce-Anwendungen eingesetzt, da ihre einfache Struktur in Zeiten mit hohem Datenverkehr leicht skalierbar ist. Diese Agilität ist für Gaming-, AdTech- und IoT-Anwendungen von großem Nutzen. 

Die Anforderung großer Unternehmen, Services ohne Latenzzeiten bereitzustellen und schneller zu skalieren, hat die Verbreitung von Microservices vorangetrieben. Dies hat die Unternehmen dazu veranlasst zu prüfen, welche Arten von Datenbanken sich für die verschiedenen Anwendungen eignen. 

Unternehmen haben festgestellt, dass die Verwendung einer einzigen relationalen Datenbank für jede Anwendungskomponente ihre Grenzen hat, insbesondere wenn es für bestimmte Komponenten bessere Alternativen gibt. Microservices sind unter anderem deshalb eine attraktive Option, weil sich hierdurch die Notwendigkeit eines einzigen, gemeinsam genutzten Datenspeichers für eine gesamte Anwendung erübrigt. Stattdessen besteht die Anwendung aus vielen, lose gekoppelten und unabhängig voneinander einsetzbaren Services, die jeweils über ein eigenes Datenmodell und eine eigene Datenbank verfügen und über API-Gateways oder iPaaS integriert werden. 

Das Muster der Verwendung mehrerer Datenbanken innerhalb einer einzigen Anwendung, auch bekannt als polyglotte Persistenz, hat zu dem Markterfolg der NoSQL-Datenbanken beigetragen. Heute können Entwickler die richtige Datenbank für den richtigen Microservice nutzen, ohne dass sie versuchen müssen, alle Anforderungen im Kontext einer einzigen relationalen Datenbank zu erfüllen.