Wenn SQL nicht ausreicht

Relationale Datenbankmanagementsysteme(RBDMS), die SQL verwenden, werden seit Jahrzehnten zur Speicherung von Anwendungsdaten eingesetzt. Das relationale Modell der Organisation von Daten in Tabellen mit einem identifizierenden Schlüssel für jede Zeile hat sich als zuverlässig und effizient erwiesen und bildet das Rückgrat wichtiger Branchen wie dem Gesundheits- und Finanzwesen. Moderne SQL-Datenbanken wie MySQL und PostgreSQL gehören nach wie vor zu den beliebtesten Datenbanken, die heute verwendet werden. Aber wann ist SQL nicht genug?

Der Aufstieg von NoSQL-Datenbanken(NotOnlySQL) ab Ende der 2000er Jahre fiel mit vielen anderen Fortschritten zusammen. Multicore-Prozessoren und Virtualisierung wurden alltäglich, die Cloud war auf dem Vormarsch, und Millionen von Nutzern auf der ganzen Welt gingen zum ersten Mal mit Smartphones online. Alles musste wachsen, und der praktischste Weg, diese dringend benötigte Skalierung zu erreichen, ist horizontale Skalierung. Die Gegenüberstellung von SQL und NoSQL wird oft vereinfacht als "SQL kann vertikal und NoSQL horizontal skalieren", aber das ist unvollständig und falsch.

Horizontale Skalierung

Wenn wir von horizontaler Skalierung sprechen, meinen wir die Erweiterung unserer Umgebung durch Hinzufügen weiterer Knoten oder Maschinen. Während SQL-Datenbanken relativ einfach vertikal skaliert werden können, indem man einem einzelnen Knoten mehr Arbeitsspeicher und Rechenleistung hinzufügt, ist die Verteilung Ihres Datensatzes auf mehrere Knoten eine größere Herausforderung. Dies lässt sich mit einer Technik bewerkstelligen, die Sharding. Bei der Arbeit mit großen Datensätzen und hohem Durchsatz hilft Sharding, die Belastung eines einzelnen Servers zu verringern und ermöglicht eine Skalierung durch Hinzufügen oder Entfernen von Servern, je nach Bedarf.

MySQL Sharding und Beschränkungen

SQL-Datenbanken können durch Sharding horizontal skaliert werden. Die Methode und die unterstützten Funktionen unterscheiden sich erheblich von Datenbank zu Datenbank, aber es gibt auch einige Vorbehalte zu beachten. Konzentrieren wir uns auf eines der gängigsten Beispiele - MySQL mit der NDB-Speicher-Engine. MySQL unterstützt NDB-Cluster, die eine einzelne, große Tabelle in mehrere kleinere Tabellen aufteilen können. Der Vorgang des Aufteilens einer Tabelle wird als Partitionierung bezeichnet. Wenn sie auf mehreren Servern gespeichert werden, bilden diese kleineren Tabellen die Shards. Die Datenbanken in Ihrem Cluster speichern jeweils einen der Shards. Zusammen bilden die Datenbanken im Cluster Ihren vollständigen Datensatz. 

Die Verwendung von Sharding in SQL-Datenbanken kann eine sehr hohe Skalierung der Datensatzgröße bieten, aber sie kann auch Ihre Anwendungslogik komplexer machen. Sie müssen sorgfältig konfigurieren, wie Ihre Daten in mehrere Shards aufgeteilt werden, denn diese Entscheidung wirkt sich auf die Gesamtleistung der Datenbank aus. Neben der Komplexität und dem hohen Zeitaufwand gibt es auch technische Hürden zu beachten. Um einer häufig genannten Einschränkung entgegenzuwirken, kann MySQL so konfiguriert werden, dass es Join-Operationen über mehrere Shards hinweg durchführt, allerdings auf Kosten der Leistung bei größeren Skalen. Dies kann analytische Funktionen in solchen Umgebungen unpraktisch machen.

NoSQL eingeben

Viele verschiedene Arten von NoSQL-Datenbanken sind seit ihrer Einführung in den späten 2000er Jahren explosionsartig in Gebrauch gekommen. In diesem Beispiel werden wir uns auf die beliebteste NoSQL-Datenbank, MongoDB, konzentrieren. MongoDB (abgeleitet von dem Wort "humongous") ist dokumentenorientiert. Die Daten werden in Dokumenten gespeichert, die JSON-Objekten ähneln, und jedes Dokument enthält Paare von Feldern und Werten. Dies steht im Gegensatz zu SQL-Datenbanken, die Tabellen und Zeilen zur Formatierung von Daten verwenden. Vielleicht haben Sie gelesen, dass NoSQL-Datenbanken wie MongoDB in der Regel besser für die horizontale Skalierung geeignet sind.

Beachten Sie, dass MongoDB speziell ein Format namens BSON verwendet, das von JSON abgeleitet ist, aber das ist bei jeder Datenbank anders.

Schemata und Scherben

MongoDB ist schemalos (oder schemafrei), d. h. es erfordert keine definierte Organisationsstruktur auf Datenbankebene. Das Schema wird stattdessen auf der Anwendungsebene in den Code eingebaut, was uns viel Flexibilität gibt, um die Struktur später zu ändern, während unsere Daten erhalten bleiben. Zwar fehlt ihnen die strikt erzwungene Konsistenz von ACID-konformen SQL-Datenbanken, doch zeichnen sich MongoDB und andere NoSQL-Datenbanken durch ihre Verfügbarkeit und Partitionstoleranz aus.

Als wir uns mit der horizontalen Skalierung von SQL-Datenbanken befassten, haben wir den Prozess der Aufteilung einer Tabelle in Shards besprochen. Dies ist zwar möglich, bringt aber aufgrund der starren Struktur der Datenbank zahlreiche Einschränkungen mit sich. MongoDB und andere NoSQL-Datenbanken hingegen sind so konzipiert, dass sie Sharding auf struktureller Ebene unterstützen. Ein Shard ist eine Teilmenge von Daten, und MongoDB ermöglicht eine horizontale Skalierung, indem Shards als Replikatsätze bereitgestellt werden. Replikatsätze sind Cluster aus mindestens drei Knoten mit redundanten Kopien der gleichen Daten. Sie bieten Verfügbarkeit und Redundanz, wenn sie über große Umgebungen verteilt sind und nicht durch ein vorgegebenes Schema eingeschränkt werden.

Daraus können wir sofort die Zugeständnisse erkennen, die NoSQL-Datenbanken machen, um skalierbar zu sein. NoSQL-Datenbanken benötigen oft deutlich mehr Speicherplatz als SQL-Datenbanken, da eine größere Menge an redundanten Daten erforderlich ist, um die Verfügbarkeit über große horizontale Bereitstellungen hinweg zu gewährleisten. Die Schreibgeschwindigkeit von NoSQL-Datenbanken ist in der Regel höher als die von SQL-Datenbanken, aber die Abfragen sind langsamer. Da NoSQL-Datenbanken keine definierte Struktur haben, sind sie von Natur aus nicht ACID-konform, was sie für Anwendungen, die große Mengen von Finanztransaktionen verarbeiten, weniger geeignet macht. Alternativ können wir massive verteilte NoSQL-Cluster konfigurieren, die die Leistung aufrechterhalten und damit ideale Kandidaten für Big Data und Analysen sind. 

Wann ist SQL also nicht genug? Wie zu erwarten, ist die Antwort nicht einfach, aber es gibt einige allgemeine Richtlinien, die wir bei der Entwicklung unserer Anwendungen berücksichtigen können. Was muss unsere Anwendung leisten und wie groß muss sie sein? Davon ausgehend können wir entscheiden, was unsere oberste Priorität ist. Die Aussage "SQL skaliert vertikal und NoSQL skaliert horizontal" ist nicht wahr, aber wir können sagen, dass die meisten SQL-Datenbanken mit dem Ziel der Konsistenz entwickelt wurden, während die meisten NoSQL-Datenbanken für die Skalierung entwickelt wurden.  

Es wird immer Gegensätze zu dieser allgemeinen Leitlinie geben. MySQL lässt sich horizontal skalieren, und MongoDB unterstützt seit kurzem Multi-Document ACID-Transaktionen. Je mehr wir verstehen, wie diese Datenbanken konzipiert sind, desto besser können wir das beste Werkzeug für die jeweilige Aufgabe auswählen.

Bereitstellen von Datenbanken auf Linode

Erfahren Sie mehr über Linode Managed Databases oder melden Sie sich an, um Updates für Ihre bevorzugte Datenbank-Engine zu erhalten. Sie können auch verwaltete Datenbanksysteme wie MongoDB von der Linode Marketplace bereitstellen oder unseren Anleitungen zur Installation einer Datenbank auf einer Vielzahl von Linux-Distributionen folgen, wie z.B. MongoDB auf CentOS 7 installieren.