Startseite > Datacenter & Verkabelung > Erfolgreich Skalieren mit verteiltem SQL

Gastbeitrag von MariaDB

Erfolgreich Skalieren mit verteiltem SQL

11. Februar 2021, 7:00 Uhr | Shane Johnson/am

Fortsetzung des Artikels von Teil 1

Erfolgreich skalieren

Bis vor Kurzem existierten nur wenige Möglichkeiten, relationale Datenbanken zu skalieren. Eine erste Möglichkeit bestand darin, einen vorhandenen Server durch einen größeren zu ersetzen. Waren die Kapazitäten dieses Servers ausgeschöpft, wandten sich einige Unternehmen Hardware-Lösungen wie Oracle Exadata zu.

Die zweite Möglichkeit war das Skalieren durch Fragmentierung, also der verstreuten Speicherung von logisch zusammengehörigen Clustern. Diese Möglichkeit nutzten primär große Technikunternehmen mit einem sehr guten technischen Verständnis sowie Unternehmen, die nicht bereit oder in der Lage waren, riesige Investitionen in die Hardware zu tätigen. Der Vorteil dabei ist, dass die Fragmentierung kosteneffizienter als die erste Methode ist. Auf der anderen Seite neigen solche Systeme dazu, sowohl sehr wartungsintensiv als auch nur begrenzt leistungsfähig zu sein, da sie oft auf die Unterstützung bestimmter Anwendungen und Abfragen spezialisiert sind.

Verteiltes SQL hingegen bietet uneingeschränkte Skalierbarkeit für jede Anwendung. Dadurch sind große Investitionen in zusätzliche Hardware nicht nötig. Darüber hinaus können einige verteilte SQL-Datenbanken Daten auf verschiedene Instanzen verteilen. Dabei prüfen sie ständig, ob die Daten optimal verteilt sind. Falls sich das Nutzerverhalten ändert oder bei Anwendungsentwicklungen, erfolgt die Prüfung, ob sich durch Verschieben der Daten zwischen einzelnen Knoten die Leistung verbessern lässt.

Diese Flexibilität hält Ausfallzeiten und somit Kosten gering. Ein Beispiel aus der Praxis: Bei manchen Unternehmen sind bis zu 100 Datenbank-Instanzen erforderlich, um ihre Spitzenlastbedingungen („peak traffic conditions”) zu erfüllen. Diese Anzahl an Instanzen ist allerdings nur während eines kurzen Zeitraums nötig. Mit verteiltem SQL können Nutzer, je nach verwendeter Lösung, stundenweise Instanzen hinzufügen und sie wieder entfernen und die Kosten somit auf ein Minimum senken. In der Cloud geht dies per Knopfdruck. Außerdem sind Daten immer gleichmäßig verteilt, beispielsweise bei Hinzufügen oder Entfernen von Knoten. Durch diesen Ansatz der automatischen Datenverteilung muss man verschiedene Fragmente nicht individuell verwalten und die Daten bleiben auch bei dem Verlust eines Knotens noch verfügbar.

Eine der Grundannahmen hinter verteiltem SQL lautet, dass die Ausfallwahrscheinlichkeit einer Instanz mit einer größeren Anzahl von Instanzen in einer verteilten Datenbank steigt. Falls es zu einem Ausfall der Infrastruktur kommt, bleiben die Daten dennoch verfügbar, da sie auf andere Knoten repliziert sind. Weil Instanzen ohne Vorankündigung ausfallen können, verarbeiten die Datenbanken Topologieänderungen automatisch. Damit hilft verteiltes SQL Unternehmen dabei, sowohl durch Ausfälle entstandene Kosten sowie ebenfalls durch Ausfälle hervorgerufene Vertrauensverluste seitens der Nutzer zu vermeiden.

Keine Kompromisse bei Datenbanken

Verantwortliche Teams müssen sicherstellen, dass Unternehmensdaten dauerhaft, sicher und konsistent gehalten sind. Darüber hinaus müssen Datenbanken immer verfügbar und weiterhin skalierbar sein. Dies ist von entscheidender Bedeutung für den Erfolg eines Unternehmens. Früher waren nur wenige Datenbanken in der Lage, diesen Grad an Funktionalität zu garantieren. Daher mussten Anwender etliche Kompromisse eingehen. Beispielsweise mussten sie teils auf Datenintegrität und Transaktionen verzichten, um Skalierbarkeit zu erreichen. Ein Grund für diese Einschränkungen waren die vielen technischen Herausforderungen, die mit der sicheren Durchführung von Transaktionen über mehrere Datenbankinstanzen hinweg verbunden sind, beispielsweise hinsichtlich der ACID-Konformität. Verteiltes SQL hingegen kann viele dieser Probleme lösen.

Blick in die Zukunft

Verteiltes SQL befindet sich in einer beständigen Weiterentwicklung, denn die Nachfrage des Marktes nach zuverlässigen, transparenten und genauen Daten ist hoch. Da es sich bei verteiltem SQL um eine speziell für Cloud entwickelte Technik handelt, ist sie per Definition cloud-nativ. Und wenn es etwas gibt, worüber sich Technik- und Geschäftswelt einig sind, dann, dass der Wechsel in die Cloud unaufhaltsam ist.

Shane Johnson ist Senior Director of Product Marketing bei MariaDB, www.mariadb.com.