Mehrwert von Distributed SQL richtig nutzen Verteiltes SQL – die Alternative zum Sharding

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Confluent Germany GmbH

MariaDB Corporation Ab

Verteilte SQL-Datenbanken sind so konzipiert, dass sie nahezu linear skalieren. Dieser Artikel geht auf die Grundlagen ein und erläutert, wie man loslegen kann.

Sharding ist eine beliebte Strategie, um die Begrenzungen eines einzelnen Datenbankservers zu überwinden. Letztlich sind dessen Ressourcen immer begrenzt: Entweder ist der Server nicht ausreichend leistungsfähig genug, um eine große Menge an Lese- oder Schreibvorgängen auszuführen, oder seine Storage-Kapazität ist erschöpft.

Das Sharding umgeht diese Begrenzungen und hilft dabei, Schreibvorgänge zu skalieren. Dabei wird die Datenbank in kleinere Teile, die sogenannten Shards aufgeteilt und über mehrere Datenbankserver verteilt. Dadurch entsteht ein sogenannter Sharding-Cluster, bei dem die Belastung jedes einzelnen Knotens kleiner ist. Dadurch wird sich die Schreibkapazität der gesamten Datenbank erhöhen.

Doch das ist nicht die einzige oder beste Möglichkeit, relationale Datenbanken zu skalieren. Eine auf den ersten Blick ähnlich wirkende Strategie ist verteiltes SQL (Distributed SQL), bei dem ebenfalls ein Cluster aus Datenbankservern eingesetzt wird. Die Methode ist vollständig automatisiert und transparent für alle Datenbankanwendungen. Verteilte SQL-Datenbanken sind für eine beinahe lineare Skalierung konzipiert. Dieser Beitrag erläutert einige Grundlagen von verteiltem SQL und zeigt den Einstieg in die Arbeit dieser Form von Schreibskalierung.

Herausforderungen von Database Sharding

Sharding ist weit verbreitet, birgt jedoch eine Reihe von Herausforderungen:

Partitionierung: Die Partitionierung von Daten auf mehrere Shards ist nicht einfach. Vielfach entstehen beim längeren Betrieb einer Datenbank Hotspots, also Bereiche der Datenbank, in denen besonders häufig Daten geschrieben werden. Für einige Knotenpunkte oder Maschinen entsteht somit beachtlich mehr Arbeit als andere. Ein vereinfachtes Beispiel: Der Buchstabe S ist der häufigste Anfangsbuchstabe von deutschen Nachnamen, ein Hotspot ist hier denkbar. Admins müssen die Daten gleichmäßig über die Shards verteilen, so dass benachbarte Daten keine Hotspots bilden.

Störungen und Ausfälle: Wenn ein Knoten ausfällt und nicht genügend Shards vorhanden sind, um die Arbeitslast zu übernehmen, müssen die Daten auf einen neuen Knoten übertragen werden. Dies erfordert jedoch Zeit und Rechenleistung sowie Anpassungen am Programmcode.

Komplexität der Abfragen: Der Programmcode ist an die Logik des Sharding gebunden. Abfragen auf mehreren Knoten müssen jeweils neu konfiguriert werden.

Datenkonsistenz: Datenkonsistenz über mehrere Shards hinweg ist eine große Herausforderung, da die Aktualisierungen über diese Shards hinweg koordiniert werden müssen. Das ist nicht einfach, wenn es zu gleichzeitigen Aktualisierungen kommt. In diesem Fall müssen Konflikte zwischen verschiedenen Schreibvorgängen gelöst werden.

Elastische Skalierbarkeit: Bei wachsendem Datenvolumen oder einer steigenden Zahl an Abfragen benötigt die Datenbank unter Umständen zusätzliche Shards. Die gleichmäßige Verteilung der Daten ist eine sehr komplexe Aufgabe, die manuell erfüllt werden muss und damit unvermeidbare Ausfallzeiten erfordert.

Die Herausforderungen zeigen, dass Sharding auch vergleichsweise schnell an Grenzen stößt, vor allem durch die Notwendigkeit der manuellen Aufteilung in Shards. Einige dieser Nachteile lassen sich durch den Einsatz verschiedener Datenbanken für unterschiedliche Arbeitslasten, Datenbank-Speicher-Engines mit nativen Sharding-Funktionen oder Datenbank-Proxys abmildern. Doch auch hier gibt es Grenzen und zudem erhöhen diese Verfahren die Komplexität der Gesamtdatenbank, sodass der Aufwand für die Admins deutlich steigt.

Was ist verteiltes SQL?

Verteiltes SQL ist eine neue Generation von relationalen Datenbanken. Vereinfacht ausgedrückt handelt es sich dabei um relationale Datenbanken mit transparenter Aufteilung, die für Anwendungen wie eine einzige logische Datenbank wirkt. Lese- und Schreibvorgänge werden über unterschiedliche Knoten eines Clusters verteilt, doch weder die Anwendung noch der Endanwender bemerken davon etwas.

Verteilte SQL-Datenbanken sind als Shared-Nothing-Architektur aufgebaut. Die Datenbank-Engine skaliert sowohl Lese-als auch Schreibvorgänge. Sie bietet echte ACID-Konformität und hohe Verfügbarkeit durch das Cluster-Prinzip. Insgesamt ist eine verteilte SQL-Datenbank ähnlich gut skalierbar wie eine NoSQL-Datenbank, behält dabei jedoch die für RDBMS typische Datenkonsistenz. Kurz: Verteiltes SQL hat alle Vorteile von relationalen SQL-Datenbanken und bietet zusätzlich Cloud-Kompatibilität und erhöhte Ausfallsicherheit.

Wie funktioniert verteiltes SQL?

Die Funktionen von verteiltem SQL lassen sich gut an MariaDB Xpand zeigen. Diese verteilte SQL-Datenbank ist mit der Open-Source-Datenbank MariaDB kompatibel. Sie verteilt Daten und Indizes auf verschiedene Knoten eines Datenbankclusters und führt automatisch Aufgaben wie den Datenabgleich und die verteilte Ausführung von Abfragen durch.

Solche Abfragen laufen parallel, sodass Verzögerungen nur minimal sind. Die Daten werden automatisch repliziert, sodass es keinen Single Point of Failure gibt. Wenn ein Knoten ausfällt, verteilt Xpand die Daten zwischen den übrigen Knoten neu. Dasselbe geschieht, wenn ein neuer Knoten hinzugefügt wird.

Das Entstehen von Hotspots ist beim manuellen Sharding von Datenbanken eine große Herausforderung für die Admins. Bei Xpand stellt der Rebalancer sicher, dass es keine Hotspots gibt. Er erkennt Situationen, in denen ein Knoten zu viele Transaktionen verarbeiten muss, während andere untätig bleiben. In diesem Fall verteilt der Rebalancer die Daten automatisch neu über die einzelnen Knoten. Dies geschieht transparent für Anwendungen. Die neuen Funktionen und Möglichkeiten von verteilten SQL lassen sich am besten an einem Beispiel demonstrieren, wie es in der folgenden Bildergalerie dargestellt ist.

Bildergalerie

Bildergalerie mit 6 Bildern

Diese Architektur ermöglicht eine nahezu lineare und automatisch ablaufende Skalierung der Datenbank. Manuelle Eingriffe auf der Anwendungsebene sind nicht erforderlich. Der Cluster sieht für jede Art von Anwendung wie eine einzige logische Datenbank aus. So ist es für Anwendungen nicht möglich, sich direkt mit dem Cluster zu verbinden.

Stattdessen nutzen wir einen Datenbank-Proxy, der auch als Load Balancer arbeitet. Bei Xpand ist das MariaDB MaxScale. Der Proxy sorgt dafür, dass alle Lese- und Schreibzugriffe transparent ausgeführt werden, wie im vorangestellten Bild zu sehen.

Wenn die Anwendung einen Schreibvorgang sendet (z. B. INSERT oder UPDATE), wird der Hash berechnet und die Transaktion an den richtigen Slice weitergeleitet. Mehrere Schreibvorgänge werden parallel an mehrere Knoten geschickt.

Gründe gegen den Einsatz von verteiltem SQL

Verteiltes SQL ist nicht für jedes Anwendungsszenario die ideale Lösung. So verbessert die Aufteilung der Daten zwar die Leistung, erhöht aber auch den Overhead bei der Kommunikation zwischen den Knoten. Dies kann zu einem Absinken der Leistung führen, wenn die Datenbank nicht richtig konfiguriert oder der Loadbalancer nicht optimiert ist.

Verteiltes SQL ist auf jeden Fall empfehlenswert für Datenbankanwendungen, die mehr als 10.000 Abfragen oder 5.000 Transaktionen pro Sekunde bewältigen müssen. Weniger beanspruchte Datenbanksysteme oder solche mit vielen kleinen Tabellen sind unter Umständen für eine herkömmliche, monolithische Datenbank besser geeignet.

Erste Schritte mit verteiltem SQL

Da eine verteilte SQL-Datenbank für eine Anwendung so aussieht, als wäre sie eine einzige logische Datenbank, ist der Einstieg sehr einfach. Folgendes benötigen wir dafür:

• Einen SQL-Client (DBeaver, DbGate oder DataGrip) oder eine beliebige SQL-Client-Erweiterung für Ihre IDE.

• Eine verteilte SQL-Datenbank.

Docker macht den zweiten Teil einfach. Bei MariaDB gibt es beispielsweise das Docker-Image mariadb/xpand-single. Es enthält eine Xpand-Datenbank mit einem Knoten, die sich für Evaluierung, Tests und die Entwicklung eignet.

Um einen Xpand-Container zu starten, führen wir den folgenden Befehl aus:

Einzelheiten finden sich in der Docker-Image-Dokumentation.

Hinweis: Zum Redaktionsschluss war das Docker-Image mariadb/xpand-single nicht für die ARM-Architektur verfügbar. Hier ist der Umweg über ein Virtualisierungs- oder Emulationstool wie UTM und eine damit installierte Linux-Distribution wie Debian notwendig, um dort Docker zu starten und den MariaDB Xpand-Container manuell zu erstellen. Zu beachten ist, dass emulierte Software viel langsamer läuft als native Software. Das Xpand-Docker-Image ist ein gutes Werkzeug, um sicherzustellen, dass eine Anwendung funktioniert, bevor sie zu einem Produktionscluster wechselt, wie sie auf SkySQL verfügbar sind.

Mit der Datenbank verbinden

Die Verbindung zu Xpand funktioniert auf die gleiche Weise wie zu einem MariaDB Community- oder Enterprise-Server. Wenn Sie den CLI von MariaDB installiert haben, führen Sie einfach folgendes aus:

Auch grafische Benutzeroberflächen für SQL-Datenbanken wie DBeaver, DataGrip oder eine SQL-Erweiterung für die IDE (wie diese für VS Code) eignen sich für die Verbindung mit Xpand. Das Beispiel zeigt, wie der kostenlose, quelloffene SQL-Client DbGate eingesetzt wird.

DbGate arbeitet als Desktop-Anwendung, kann aber auch als Webanwendung für den Einsatz mit einem Browser bereitgestellt werden (ähnlich wie phpMyAdmin). Führen Sie einfach den folgenden Befehl aus:

Sobald der Container gestartet ist, rufen wir im Browser die Seite http://localhost:3000/ auf. Dort füllen wir die Verbindungsdaten aus. Mit einem Klick auf die Test-Schaltfläche lässt sich verifizieren, dass die Verbindung erfolgreich ist. Nun klicken wir auf „Speichern“ und erstellen eine neue Datenbank.

Dafür klicken wir mit der rechten Maustaste auf die Verbindung im linken Fenster und wählen „Datenbank erstellen“. Nun können wir Tabellen erzeugen und SQL-Skripte importieren. Für umfangreichere Experimente und Tests sind Nation oder Sakila empfehlenswerte Beispieldatenbanken.

Java, JavaScript, Python und C++ nutzen

Xpand unterstützt über die MariaDB-Konnektoren eine Vielzahl an unterschiedlichen Programmiersprachen und Entwicklungs-Frameworks. Auf der Webseite von MariaDB finden sich auch zahlreiche Code-Beispiele für Java, JavaScript, Python und C++.

Verteiltes SQL: Leistungsfähig und automatisiert

Die Stärke einer verteilten SQL-Datenbank liegt in ihrer Fähigkeit, Lese- und Schreibzugriffe transparent und automatisch zu skalieren. Dafür reicht es, einfach weitere Knoten hinzuzufügen. Der in die Datenbank integrierte Rebalancer kümmert sich darum, die Daten optimal über die verfügbaren Knoten zu verteilen. Das Datenbanksystem eignet sich dafür, in einer Multi-Node-Topologie aus eigenen Servern „on premises“ genutzt zu werden. Doch für die meisten Unternehmen wird der Produktivbetrieb in der Cloud (SkySQL) die beste Lösung sein.

* Alejandro Duarte ist ein preisgekrönter Softwareentwickler, Autor und Developer Advocate bei MariaDB plc. Er begann im Alter von 13 Jahren mit dem Programmieren und machte 2012 seinen Abschluss in Informatik. Mit drei veröffentlichten Büchern und einer Vielzahl von Artikeln, Videos und Vorträgen auf internationalen Java-Konferenzen und in Java User Groups gehört Alejandro Duarte zu den bekanntesten Gesichter in der Java-Community. Sie können ihn über seinen persönlichen Blog ProgrammingBrain.com oder auf Twitter via @alejandro_du kontaktieren.

(ID:49582614)