Was ist NoSQL? Datenbanken für eine Zukunft im Cloud-Maßstab

Eine der grundlegendsten Entscheidungen bei der Entwicklung einer Anwendung ist die Verwendung einer SQL- oder NoSQL-Datenbank zum Speichern der Daten. Herkömmliche SQL-Datenbanken (dh relationale Datenbanken) sind das Ergebnis jahrzehntelanger technologischer Entwicklung, bewährter Verfahren und realer Stresstests. Sie sind für zuverlässige Transaktionen und Ad-hoc-Anfragen konzipiert, die Grundvoraussetzungen für Branchenanwendungen. Sie sind jedoch auch mit Einschränkungen wie einem starren Schema belastet, die sie für andere Arten von Apps weniger geeignet machen.

Als Reaktion auf diese Einschränkungen entstanden NoSQL-Datenbanken. NoSQL-Systeme speichern und verwalten Daten auf eine Weise, die eine hohe Betriebsgeschwindigkeit und große Flexibilität seitens der Entwickler ermöglicht. Viele wurden von Unternehmen wie Google, Amazon, Yahoo und Facebook entwickelt, die nach besseren Möglichkeiten suchten, Inhalte zu speichern oder Daten für massive Websites zu verarbeiten. Im Gegensatz zu SQL-Datenbanken können viele NoSQL-Datenbanken horizontal über Hunderte oder Tausende von Servern skaliert werden.

Die Vorteile von NoSQL sind jedoch nicht ohne Kosten. NoSQL-Systeme bieten im Allgemeinen nicht die gleiche Datenkonsistenz wie SQL-Datenbanken. Während SQL-Datenbanken traditionell die Leistung und Skalierbarkeit der ACID-Eigenschaften hinter zuverlässigen Transaktionen geopfert haben, haben NoSQL-Datenbanken diese ACID-Garantien für Geschwindigkeit und Skalierbarkeit weitgehend aufgegeben.

Kurz gesagt, SQL- und NoSQL-Datenbanken bieten unterschiedliche Kompromisse. Während sie im Kontext eines bestimmten Projekts konkurrieren können - wie bei der Auswahl für diese oder jene Anwendung -, ergänzen sie sich im Großen und Ganzen. Jedes ist für verschiedene Anwendungsfälle geeignet. Die Entscheidung ist weniger ein Fall von entweder / oder vielmehr eine Frage, welches Werkzeug für den Job geeignet ist.

NoSQL vs. SQL

Der grundlegende Unterschied zwischen SQL und NoSQL ist nicht allzu kompliziert. Jeder hat eine andere Philosophie, wie Daten gespeichert und abgerufen werden sollen.

Bei SQL-Datenbanken haben alle Daten eine inhärente Struktur. Eine herkömmliche Datenbank wie Microsoft SQL Server, MySQL oder Oracle Database verwendet ein Schema - eine formale Definition, wie in die Datenbank eingefügte Daten zusammengesetzt werden. Beispielsweise kann eine bestimmte Spalte in einer Tabelle nur auf Ganzzahlen beschränkt sein. Infolgedessen weisen die in der Spalte aufgezeichneten Daten einen hohen Normalisierungsgrad auf. Das starre Schema einer SQL-Datenbank macht es auch relativ einfach, Aggregationen an den Daten durchzuführen, beispielsweise über JOINs.

Mit NoSQL können Daten schemalos oder in Freiform gespeichert werden. Alle Daten können in jedem Datensatz gespeichert werden. Unter den NoSQL-Datenbanken finden Sie vier gängige Modelle zum Speichern von Daten, die zu vier gängigen Typen von NoSQL-Systemen führen:

  1. Dokumentendatenbanken (zB CouchDB, MongoDB). Eingefügte Daten werden in Form von Freiform-JSON-Strukturen oder „Dokumenten“ gespeichert, wobei die Daten von Ganzzahlen über Zeichenfolgen bis hin zu Freiformtext reichen können. Es ist nicht unbedingt erforderlich anzugeben, welche Felder ein Dokument gegebenenfalls enthalten soll.
  2. Schlüsselwertspeicher (z. B. Redis, Riak). Auf Freiformwerte - von einfachen Ganzzahlen oder Zeichenfolgen bis hin zu komplexen JSON-Dokumenten - wird in der Datenbank über Schlüssel zugegriffen.
  3. Breite Spaltenspeicher (zB HBase, Cassandra). Daten werden wie in einem herkömmlichen SQL-System in Spalten anstelle von Zeilen gespeichert. Eine beliebige Anzahl von Spalten (und daher viele verschiedene Datentypen) kann nach Bedarf für Abfragen oder Datenansichten gruppiert oder aggregiert werden.
  4. Grafikdatenbanken (zB Neo4j). Daten werden als Netzwerk oder Diagramm von Entitäten und ihren Beziehungen dargestellt, wobei jeder Knoten im Diagramm ein Freiform-Datenblock ist.

Die schemalose Datenspeicherung ist in den folgenden Szenarien nützlich:

  1. Sie möchten einen schnellen Zugriff auf die Daten und legen mehr Wert auf Geschwindigkeit und Einfachheit des Zugriffs als auf zuverlässige Transaktionen oder Konsistenz.
  2. Sie speichern eine große Datenmenge und möchten sich nicht an ein Schema binden, da das spätere Ändern des Schemas langsam und schmerzhaft sein kann.
  3. Sie nehmen unstrukturierte Daten aus einer oder mehreren Quellen auf, aus denen sie stammen, und möchten die Daten für maximale Flexibilität in ihrer ursprünglichen Form beibehalten.
  4. Sie möchten Daten in einer hierarchischen Struktur speichern, möchten jedoch, dass diese Hierarchien durch die Daten selbst beschrieben werden, nicht durch ein externes Schema. Mit NoSQL können Daten auf eine Weise, die für die Emulation von SQL-Datenbanken komplexer ist, beiläufig selbstreferenziell sein.

Abfragen von NoSQL-Datenbanken

Die von herkömmlichen Datenbanken verwendete strukturierte Abfragesprache bietet eine einheitliche Möglichkeit zur Kommunikation mit dem Server beim Speichern und Abrufen von Daten. Die SQL-Syntax ist stark standardisiert. Während einzelne Datenbanken bestimmte Vorgänge unterschiedlich behandeln können (z. B. Fensterfunktionen), bleiben die Grundlagen gleich.

Im Gegensatz dazu verfügt jede NoSQL-Datenbank über eine eigene Syntax zum Abfragen und Verwalten der Daten. CouchDB verwendet beispielsweise Anforderungen in Form von JSON, die über HTTP gesendet werden, um Dokumente zu erstellen oder aus seiner Datenbank abzurufen. MongoDB sendet JSON-Objekte über ein Binärprotokoll über eine Befehlszeilenschnittstelle oder eine Sprachbibliothek.

Einige NoSQL-Produkte können SQL-ähnliche Syntax verwenden, um mit Daten zu arbeiten, jedoch nur in begrenztem Umfang. Zum Beispiel hat Apache Cassandra, eine Spaltenspeicherdatenbank, eine eigene SQL-ähnliche Sprache, die Cassandra Query Language oder CQL. Einige der CQL-Syntax stammen direkt aus dem SQL-Playbook, z. B. die Schlüsselwörter SELECT oder INSERT. Es gibt jedoch keine Möglichkeit, eine JOIN- oder Unterabfrage in Cassandra durchzuführen, und daher sind die zugehörigen Schlüsselwörter in CQL nicht vorhanden.

Shared-Nothing-Architektur

Eine Design-Wahl, die NoSQL-Systemen gemeinsam ist, ist eine "Shared-Nothing" -Architektur. In einem Shared-Nothing-Design arbeitet jeder Serverknoten im Cluster unabhängig von jedem anderen Knoten. Das System muss nicht von jedem einzelnen Knoten einen Konsens erhalten, um ein Datenelement an einen Client zurückzugeben. Abfragen sind schnell, da sie von dem Knoten zurückgegeben werden können, der am nächsten oder am bequemsten ist.

Ein weiterer Vorteil von Shared-Nothing ist die Ausfallsicherheit und das Scale-out. Das Skalieren des Clusters ist so einfach wie das Hochfahren neuer Knoten im Cluster und das Warten auf deren Synchronisierung mit den anderen. Wenn ein NoSQL-Knoten ausfällt, tuckern die anderen Server im Cluster weiter. Alle Daten bleiben verfügbar, auch wenn weniger Knoten für die Bearbeitung von Anforderungen verfügbar sind.

Beachten Sie, dass ein Shared-Nothing-Design nicht ausschließlich für NoSQL-Datenbanken gilt. Viele herkömmliche SQL-Systeme können auf eine Art und Weise eingerichtet werden, bei der nichts gemeinsam genutzt wird. Dies bedeutet jedoch normalerweise, dass die Konsistenz im gesamten Cluster für die Leistung beeinträchtigt wird.

NoSQL-Einschränkungen

Wenn NoSQL so viel Freiheit und Flexibilität bietet, warum nicht ganz auf SQL verzichten? Die einfache Antwort: Viele Anwendungen fordern immer noch die Einschränkungen, Konsistenz und Schutzmaßnahmen, die SQL-Datenbanken bieten. In diesen Fällen können einige „Vorteile“ von NoSQL zu Nachteilen führen. Weitere Einschränkungen ergeben sich aus der Tatsache, dass NoSQL-Systeme relativ neu sind. 

Kein Schema

Selbst wenn Sie Freiformdaten aufnehmen, müssen Sie diese fast immer einschränken, um sie nützlich zu machen. Bei NoSQL bedeutet das Auferlegen von Einschränkungen, dass die Verantwortung von der Datenbank auf den Anwendungsentwickler verlagert wird. Zum Beispiel könnte der Entwickler eine Struktur durch ein objektrelationales Zuordnungssystem oder ORM auferlegen. Wenn Sie jedoch möchten, dass das Schema mit den Daten selbst lebt , führt NoSQL dies normalerweise nicht aus.

Einige NoSQL-Lösungen bieten optionale Mechanismen zur Dateneingabe und -validierung für Daten. Apache Cassandra verfügt beispielsweise über eine Reihe nativer Datentypen, die an die in herkömmlichem SQL verwendeten erinnern.

Eventuelle Konsistenz

NoSQL-Systeme bieten eine starke oder sofortige Konsistenz für eine bessere Verfügbarkeit und Leistung. Herkömmliche Datenbanken stellen sicher, dass Vorgänge atomar (alle Teile einer Transaktion sind erfolgreich oder keine erfolgreich), konsistent (alle Benutzer haben dieselbe Ansicht der Daten), isoliert (Transaktionen konkurrieren nicht) und dauerhaft (sobald sie abgeschlossen sind, überleben sie) sind ein Serverausfall).

Diese vier Eigenschaften, die zusammen als ACID bezeichnet werden, werden in den meisten NoSQL-Systemen unterschiedlich behandelt. Anstelle einer sofortigen Konsistenz im gesamten Cluster besteht aufgrund der Zeit, die zum Kopieren von Aktualisierungen auf andere Knoten im Cluster erforderlich ist , eine eventuelle Konsistenz. In den Cluster eingefügte Daten sind schließlich überall verfügbar, Sie können jedoch nicht garantieren, wann.

Die Transaktionssemantik, die in einem SQL-System garantiert, dass alle Schritte in einer Transaktion (z. B. Ausführen eines Verkaufs und Reduzieren des Inventars) entweder abgeschlossen oder zurückgesetzt werden, ist in NoSQL normalerweise nicht verfügbar. Für jedes System, in dem es eine „einzige Quelle der Wahrheit“ geben muss, wie z. B. eine Bank, funktioniert der NoSQL-Ansatz nicht gut. Sie möchten nicht, dass Ihr Bankguthaben je nach Geldautomat unterschiedlich ist. Sie möchten, dass es überall als dasselbe gemeldet wird.

Einige NoSQL-Datenbanken verfügen über teilweise Mechanismen, um dies zu umgehen. Beispielsweise verfügt MongoDB über Konsistenzgarantien für einzelne Vorgänge, jedoch nicht für die gesamte Datenbank. Mit Microsoft Azure CosmosDB können Sie eine Konsistenzstufe pro Anforderung auswählen, damit Sie das Verhalten auswählen können, das Ihrem Anwendungsfall entspricht. Erwarten Sie jedoch mit NoSQL eine eventuelle Konsistenz als Standardverhalten.

NoSQL-Lock-In

Die meisten NoSQL-Systeme sind konzeptionell ähnlich, werden jedoch sehr unterschiedlich implementiert . Jedes hat seine eigenen Metaphern und Mechanismen für die Abfrage und Verwaltung von Daten.

Ein Nebeneffekt davon ist ein potenziell hoher Grad an Kopplung zwischen der Anwendungslogik und der Datenbank. Das ist nicht so schlimm, wenn Sie sich für ein NoSQL-System entscheiden und dabei bleiben, aber es kann zu einem Stolperstein werden, wenn Sie später die Systeme wechseln.

Wenn Sie beispielsweise von MongoDB zu CouchDB migrieren (oder umgekehrt), müssen Sie mehr als nur Daten migrieren. Sie müssen auch die Unterschiede beim Datenzugriff und bei den programmatischen Metaphern berücksichtigen. Mit anderen Worten, Sie müssen die Teile Ihrer Anwendung neu schreiben, die auf die Datenbank zugreifen.

NoSQL-Kenntnisse

Ein weiterer Nachteil von NoSQL ist der relative Mangel an Fachwissen. Wo der Markt für konventionelle SQL-Talente noch recht groß ist, entsteht der Markt für NoSQL-Kenntnisse.

Als Referenz berichtet Indeed.com, dass das Volumen der Joblisten für herkömmliche SQL-Datenbanken - MySQL, Microsoft SQL Server, Oracle Database usw. - Ende 2017 in den letzten drei Jahren höher geblieben ist als das Volumen der Jobs für MongoDB, Couchbase und Cassandra. Die Nachfrage nach NoSQL-Know-how wächst, aber es ist immer noch ein Bruchteil des Marktes für konventionelles SQL.

Zusammenführen von SQL und NoSQL

Wir können erwarten, dass einige der Unterschiede zwischen SQL- und NoSQL-Systemen mit der Zeit verschwinden. Viele SQL-Datenbanken akzeptieren bereits JSON-Dokumente als nativen Datentyp und können Abfragen für diese Daten durchführen. Einige haben sogar native Möglichkeiten, JSON-Daten Einschränkungen aufzuerlegen, sodass sie mit den gleichen Anforderungen wie herkömmliche Zeilen- und Spaltendaten behandelt werden.

Auf der anderen Seite fügen NoSQL-Datenbanken nicht nur SQL-ähnliche Abfragesprachen hinzu, sondern auch andere Funktionen traditioneller SQL-Datenbanken. Zum Beispiel versprechen mindestens zwei Dokumentendatenbanken - MarkLogic und RavenDB - ACID-konform zu sein.

Hier und da gibt es Anzeichen dafür, dass zukünftige Generationen von Datenbanken die Paradigmen überspannen und sowohl NoSQL- als auch SQL-Funktionalität bieten werden. Die Azure Cosmos-Datenbank von Microsoft verwendet beispielsweise eine Reihe von Grundelementen unter der Haube, um das Verhalten beider Systemtypen austauschbar zu reproduzieren. Google Cloud Spanner ist eine SQL-Datenbank, die starke Konsistenz mit der horizontalen Skalierbarkeit von NoSQL-Systemen kombiniert.

Dennoch werden reine SQL- und reine NoSQL-Systeme noch viele Jahre ihren Platz haben. Wenden Sie sich an NoSQL, um einen schnellen und hoch skalierbaren Zugriff auf Freiformdaten zu erhalten. Dies ist mit einigen Kosten verbunden, wie z. B. der Konsistenz der Lesevorgänge und anderen Schutzmaßnahmen, die SQL-Datenbanken gemeinsam haben. Für viele Anwendungen lohnt es sich jedoch möglicherweise, diese Schutzmaßnahmen gegen das auszutauschen, was NoSQL bietet.