Verteiltes SQL: 10 Praxistipps für ein effizientes Datenbanksystem
Die Datenbanken von Unternehmen und anderen Organisationen erreichen fantastische Größen. Noch Anfang des Jahrhunderts waren Datensammlungen in Terabyte-Größe nur wenigen Anwendungsgebieten und großen Konzernen vorbehalten. Doch inzwischen ist häufig von Petabyte die Rede, also dem tausendfachen eines Terabytes. Herkömmliche Client-Server-Datenbanken kommen hier an ihre Grenzen. Diese Systeme basieren zumeist auf dem relationalen Modell und sind ursprünglich für die Verarbeitung von strukturierten, meist kaufmännischen Daten in Tabellenform ausgelegt. In der Anfangszeit hat niemand an die oben geschilderten Datenmassen gedacht. So besitzen ältere MySQL-Versionen eine Begrenzung der Tabellengröße auf 4 GB – aus heutiger Sicht winzig. Neuere Versionen sind nicht mehr begrenzt. Die Maximalgröße einer einzelnen Datentabelle in MySQL beträgt inzwischen eher theoretische 64 Petabyte.
Beschränkungen entstehen in erster Linie durch die genutzte Hardware und Betriebssystemparameter, etwa acht Petabyte Dateisystemgröße bei Windows Server 2019. Denn die einzige Möglichkeit, ein klassisches Server-RDBMS (Relational Database Management System) zu skalieren, ist die Migration auf leistungsfähigere Hardware. Doch sie ist immer begrenzt, so dass andere Lösungen nötig sind, zum Beispiel verteiltes SQL.
So funktioniert verteiltes SQL
Eine verteilte SQL-Datenbank besteht aus mehreren Datenbankinstanzen, die als Knoten in einem Cluster zusammenarbeiten. Jeder Knoten ist dabei als (virtueller oder physischer) Server zu verstehen, der nur eine Teilmenge der Daten speichert. Bedingt durch die Architektur eines Clusters ist es einfach möglich, weitere Instanzen hinzuzufügen, um die Speicherkapazität und die Abfrageleistung zu erhöhen. Alle Kopien der Daten werden gleichzeitig synchronisiert, was eine hohe Konsistenz gewährleistet.
Verteiltes SQL wird dabei als sogenannte "Shared-Nothing-Architektur" gestaltet: Die einzelnen Knoten arbeiten unabhängig voneinander und von jedem Teil (Slice) der Datenbank existieren ein oder mehrere Replikate, um möglichst große Redundanz und damit Ausfallsicherheit zu erreichen. In einem solchen Cluster hat der Ausfall eines Knotens keine negativen Auswirkung auf die anderen Knoten oder das Netzwerk. Die restlichen Nodes bearbeiten alle Lese- und Schreibzugriffe wie gewohnt weiter. Sobald der Knoten wieder verfügbar ist, sorgt das relationale Datenbankverwaltungssystem automatisch dafür, dass Änderungen an den Daten auf allen Systemen synchronisiert werden.
Das System gleicht aber nicht nur die Daten aus, sondern sorgt auch für einen Lastausgleich bei Transaktionen. Dadurch wird ein einzelner Knoten nicht zu einem Engpass, hohe Leistung und Hochverfügbarkeit sind die Folge. Ein weiterer entscheidender Vorteil dieser Architektur ist die fast lineare horizontale Skalierung. Damit sind solche Cluster in der Lage, Millionen von Abfragen pro Sekunde zu verarbeiten, ohne dass die Datenintegrität oder die kontinuierliche Hochverfügbarkeit beeinträchtigt wird.
Die Bereitstellung von verteiltem SQL unterscheidet sich in einigen Punkten deutlich von der Arbeit mit einem herkömmlichen Client-Server-RDBMS. Die folgenden zehn Praxistipps führen von strategischen Vorüberlegungen zum Einsatz von verteiltem SQL über die Installation von MariaDB Xpand und dem zugehörigen Datenbank-Proxy MaxScale bis hin zur Optimierung der Cluster-Architektur.
1. Verteiltes SQL richtig einsetzen
Verteiltes SQL besitzt gegenüber einem traditionellen Client-Server-System einen administrativen Overhead, der besonders bei kleineren Datenbanken mit wenigen Abfragen und Transaktionen ins Gewicht fällt. Deshalb eignet sich verteiltes SQL in erster Linie für sehr große Datenbanken mit zahlreichen Transaktionen, bei denen der Overhead vernachlässigbar ist. Bei sehr großen Datenbanken werden die Abfragezeiten durch die Möglichkeit der parallelen Ausführung verkürzt. Bei weniger als 10.000 Abfragen oder 5.000 Transaktionen pro Sekunde ist verteiltes SQL normalerweise nicht die richtige Lösung.
Weniger geeignet ist verteiltes SQL zudem bei Datenbanken, die nur unstrukturierte Daten in komplexen JSON-Dateien oder Feldern im JSON-Format enthalten. Zwar kann verteiltes SQL auch JSON darstellen, doch die Datenbankleistung ist für diesen Anwendungsbereich wenig befriedigend. Es handelt sich mit einiger Sicherheit um ein Anwendungsszenario für eine dedizierte NoSQL-Dokumentendatenbank.
Ähnliches gilt für analytische Anwendungen: Verteiltes SQL ist nicht für umfangreiche Datenanalysen konzipiert, sondern primär für transaktionale Workloads. Zwar gibt es einige analytische Funktionen, die sich aber nicht für komplexe analytische Abfragen eignen. Für sie ist eine analytische Datenbank deutlich besser geeignet. Hinzu kommen alle Szenarien, in denen die Konsistenz der Daten nicht wichtig ist, etwa bei Nur-Lese-Datenbanken, deren Daten sich selten oder gar nicht ändern. Hier ist verteiltes SQL mit einiger Wahrscheinlichkeit nicht als Datenbanklösung geeignet.
2. Anwendungen, für die sich verteiltes SQL besonders eignet
Verteiltes SQL empfiehlt sich für alle Anwendungsszenarien mit den folgenden Merkmalen:
- Die Größe der Datenbank erreicht die maximalen Kapazitäten des RDBMS oder der verwendeten Hardware. Ein Datenbank-Cluster ist hier durch die gleichmäßige Verteilung der Gesamtdatenbank auf verschiedene Knoten hilfreich.
- Es gibt eine große Anzahl von gleichzeitigen Client-Verbindungen. Verteiltes SQL kann durch Verteilung der Verbindungen auf mehrere Knoten deutlich mehr gleichzeitig geöffnete Verbindungen verarbeiten.
- Hochverfügbarkeit mit hoher Fehlertoleranz ist gefragt. Sie lässt sich nur mit verteiltem SQL erreichen, da die Systeme keine primären Knoten haben und jeder Knoten den ganzen Datenverkehr bewältigt. Dadurch werden negative Folgen von Verbindungsabbrüchen zu den Clients vermieden.
- Die Anwendung ist sehr leseintensiv – durch die gleichmäßige Verteilung der Lesevorgänge über dem Cluster kommt es nicht zu Leistungseinbrüchen.
- Die Anwendung ist sehr schreibintensiv – auch hier ist verteiltes SQL überlegen, da die Schreibvorgänge gleichmäßig auf die Slices im gesamten Cluster verteilt werden.
3. Einen Cluster für verteiltes SQL richtig konfigurieren
MariaDB Xpand ist das Datenbanksystem für verteiltes SQL, das durch die Kompatibilität mit dem MariaDB Server einem Unternehmen den leichten Aufstieg von einem herkömmlichen Client-Server-System auf ein Datenbank-Cluster erlaubt. Für die Bereitstellung sind zwei Anwendungspakete nötig: Xpand und MaxScale in den jeweils aktuellen Releases. Xpand ist die Engine für verteiltes SQL und MaxScale der Datenbank-Proxy – das Backend für Anwendungen. Die Installation dieser beiden Pakete auf jedem Cluster-Server wird vorausgesetzt.
An dieser Stelle noch ein wichtiger Hinweis zu den Hardware-Voraussetzungen: Ein MaxScale-Knoten benötigt einen Acht-Kern-Prozessor und 16 GB Speicher. Die einzelnen Xpand-Knoten benötigen 8 bis 32 Kerne und jeweils 64 GB Speicher. Jeder sollte zudem mindestens 20 GiB SSD-Storage bieten. Die mögliche Anzahl der Knoten und der Prozessorkerne auf Produktivsystemen wird in der Lizenzvereinbarung festgelegt und über den Lizenzschlüssel getestet.
4. MariaDB Xpand starten und konfigurieren
MariaDB Xpand ist eine Variante des bekannten MariaDB-Open-Source-Datenbanksystems, das verteiltes SQL ermöglicht. Der Start von MariaDB Xpand setzt voraus, dass zunächst alle aktuellen Anwendungspakete auf jeder Serverinstanz installiert sind. Anschließend kann das Database Management System (DMS) auf jedem Knoten gestartet und konfiguriert werden. Dabei ist es sinnvoll, zunächst mit dem Befehl
$ clx status
zu prüfen, ob der Xpand-Service arbeitet. Dieser Befehl startet ihn bei Bedarf:
$ clx dbstart
Anschließend ist ein Root-Passwort (für root@127.0.0.1) notwendig. Dies geschieht nicht automatisch und muss manuell erledigt werden, um nicht-autorisierte Zugriffe durch lokale Root-User zu verhindern.
$ mariadb --user=root
SET PASSWORD FOR root@127.0.0.1 = PASSWORD("xpand_root_passwd");Nun folgt die Eingabe der JSON-Zeichenkette mit dem Lizenzschlüssel – zunächst nur auf einem Xpand-Knoten.
$ mariadb --user=root --password SET GLOBAL license = 'YOUR_LICENSE_KEY_JSON_GOES_HERE'; Die nächste Aufgabe: Ein Nutzerkonto für MaxScale vorbereiten: $ mariadb --user=root --password CREATE USER 'mxs'@'192.0.2.10' IDENTIFIED BY 'mxs_user_passwd';
An die Stelle von 192.0.2.10 kommt die IP-Adresse des MaxScale-Knotens. Anschließend werden die Benutzerprivilegien festgelegt:
GRANT SELECT ON system.membership TO 'mxs'@'192.0.2.10'; GRANT SELECT ON system.nodeinfo TO 'mxs'@'192.0.2.10'; GRANT SELECT ON system.softfailed_nodes TO 'mxs'@'192.0.2.10'; GRANT SELECT ON system.user_acl TO 'mxs'@'192.0.2.10'; GRANT SELECT ON system.users TO 'mxs'@'192.0.2.10';
Nun geht die Lizenzinformation von 192.0.2.1 an die weiteren Xpand-Knoten.
$ mariadb --user=root --password ALTER CLUSTER ADD '192.0.2.2', '192.0.2.3';
Noch ein Hinweis: MariaDB Xpand nutzt die beiden Benutzerkonten xpand und xpandm. Um sich damit problemlos zu verbinden, sollte SSH den Zugriff ohne Passwort per ssh-key erlauben. Informationen nennt die MariaDB-Dokumentation [1].
5. MaxScale starten und konfigurieren
MaxScale ist der Datenbank-Proxy für MariaDB Xpand. Er erzeugt eine Abstraktionsschicht zwischen der Anwendung und den Datenbanken. Für Anwendungen ist sie vollständig transparent. Aus ihrer Sicht (und damit der Entwickler- und Nutzersicht) wirkt der Proxy wie eine normale Datenbankinstanz. Er automatisiert die Verteilung der einzelnen Transaktionen auf die Knoten eines Clusters. Ebenso automatisch gelingt der Switchover bei geplanten Wartungen an einer Instanz und der Failover beim Ausfall von Knoten. MaxScale hat zudem den Vorteil, dass die Topologie des Clusters ohne Rückwirkung auf die Anwendungen veränderbar ist. MaxScale verteilt alle Transaktionen automatisch an die Knoten und sorgt für eine sofortige Leistungssteigerung.
Vor dem Start von MaxScale muss zunächst der Inhalt der vorhandenen Konfigurationsdatei /etc/maxscale.cnf ersetzt werden durch:
[maxscale] threads=auto admin_host=0.0.0.0 admin_secure_gui=false
Anschließend folgt ein Neustart von MaxScale, um die Konfigurationsdatei neu einzulesen.
$ sudosystemctl restart maxscale
Jetzt wird der gesamte Cluster dem Datenbank-Proxy bekannt gemacht:
$ maxctrl create server xpand1 192.0.2.1 $ maxctrl create server xpand2 192.0.2.2 $ maxctrl create server xpand3 192.0.2.3
In diesem Beispiel sind xpand1, xpand2 und xpand3 die Servernamen der Xpand-Knoten und 192.0.2.1, 192.0.2.2 und 192.0.2.3 ihre jeweiligen IP-Adressen. Jetzt geht es darum, den Xpand-Monitor zu starten und zu konfigurieren.
$ maxctrl create monitor xpand_monitor xpandmon \ --servers xpand1 xpand2 xpand3 \ --monitor-user=mxs \ --monitor-password=mxs_user_passwd
Statt xpand_monitor ist auch ein anderer Name möglich. Der Benutzername mxs ist bereits in der MariaDB-Konfiguration vorhanden und darf nicht geändert werden. Nun wird das Load-Balancing konfiguriert.
$ maxctrl create service xpand_service readwritesplit \ user=mxs \ password=mxs_user_passwd \ --servers xpand1 xpand2 xpand3
Zum Schluss ist noch der Listening-Port für TCP anzugeben.
$ maxctrl create listener xpand_service xpand_listener 3306 \ --protocol=MariaDBClient
6. Cluster für mehr Ausfallsicherheit regional verteilen
Die einzelnen Knoten des Clusters für verteiltes SQL können physische oder virtuelle Server sein. Zudem arbeiten sie bei Bedarf sowohl in einer On-Premises-Umgebung als auch in einem Infrastrukturservice in der Cloud. Eine wichtige Grundbedingung ist dabei die Verteilung der Knoten. Um Ausfallsicherheit und hohe Verfügbarkeit zu erreichen, sollten sie nicht gemeinsam in einem Rechenzentrum platziert werden. Für eine möglichst hohe Redundanz und Stabilität sollten die einzelnen Knoten regional verteilt sein.
So ist für Business-Continuity-Management eine Mindestanforderung, dass es eine räumliche Trennung zwischen den einzelnen Knoten des Clusters geben muss. In den KRITIS-Branchen (beispielsweise Finanzwirtschaft oder Energieversorgung) mit ihren hochkritischen Infrastrukturen ist sogar eine deutliche regionale Trennung gesetzlich gefordert. Sie wird üblicherweise über zwei geographisch entfernte Rechenzentren erfüllt. Diese regionale Trennung kann bei den großen Cloud-Providern über die sogenannten Verfügbarkeitszonen (Availability Zones, AZ) erreicht werden. Dabei handelt es sich um unterschiedliche Regionen mit jeweils eigenen Rechenzentren, die für die geographische Trennung der Clusterknoten genutzt werden. So ist beispielsweise Deutschland bei den Providern in mindestens zwei Verfügbarkeitszonen eingeteilt. Damit wird eine geographische Trennung erreicht, während gleichzeitig die datenschutzrechtliche Anforderung der Speicherung in ausschließlich deutschem Staatsgebiet erfüllt wird.
7. Die Anzahl der Knoten im Cluster korrekt bestimmen
Der kleinste mögliche Cluster für verteiltes SQL besteht aus vier dedizierten oder virtuellen Servern. Drei Server bilden den eigentlichen Datenbank-Cluster mit drei Knoten, die als Multi-Primary-Cluster zusammenarbeiten. Auf dem vierten Server läuft der Datenbank-Proxy. Er ist das Backend für Anwendungen und arbeitet zusätzlich als "Cluster-Manager".
Beim Hinzufügen oder Entfernen von Knoten müssen die Administratoren eines beachten: Die Zahl der Cluster-Knoten muss ungerade sein. Bei einer Erweiterung des grundlegenden Dreier-Clusters müssen also zwei Server hinzugefügt werden. Der Grund für diese Anforderung: Bei einem Ausfall muss die Mehrheit der Knoten verfügbar sein, damit der Datenbank-Proxy die Datenkonsistenz erhalten kann. Bei drei Knoten darf nur ein Knoten ausfallen, ohne dass es zu Problemen kommt. Dies gilt ebenfalls für vier Knoten: Die Mehrheit sind drei Knoten, es darf ebenfalls nur ein Knoten ausfallen. Diese beiden Cluster-Konfigurationen haben deshalb die gleiche Fehlertoleranz. Das Hinzufügen eines einzelnen Knotens erhöht die Verfügbarkeit also nicht. Bei fünf Knoten verhält es sich anders. Hier ist die Mehrheit zwar ebenfalls drei Knoten, aber es dürfen zwei Knoten ausfallen – die Fehlertoleranz und damit die Verfügbarkeit steigen.
8. Das automatische Rebalancing sinnvoll nutzen
Ein Teil des typischen Overheads von verteiltem SQL entsteht durch das zusätzlich notwendige Rebalancing. Damit ist die automatische Verteilung von Abschnitten (Slices) der Datenbank auf unterschiedliche Knoten gemeint. Diese Technologie benötigt eigene Rechenleistung und kann die Gesamtleistung der Datenbank phasenweise beeinträchtigen. Trotzdem ist der Einsatz des Rebalancers notwendig, um die Leistung der Datenbank zu erhalten. So können je nach Anwendungsszenario über einen längeren Zeitraum hinweg in einem Cluster sogenannte Hotspots entstehen: Knoten, in denen sich häufig genutzte Daten konzentrieren. Auf sie wird öfter lesend und schreibend zugegriffen, mit negativen Folgen für die Gesamtperformance.
Der automatisch arbeitende Rebalancer sorgt dafür, dass Leistungsverluste erkannt werden und das Slicing neu organisiert wird. Dabei achtet der Algorithmus dieses Moduls darauf, dass sich die Datenbankzugriffe möglichst gleichmäßig über die einzelnen Knoten des Clusters verteilen. In bestimmten Situationen kann das Rebalancing die Leistung der Datenbank zu stark beeinträchtigen, beispielsweise bei zeitlich begrenzten Spitzenlasten im E-Commerce. In diesem Fall ist es empfehlenswert, den Rebalancer für die Zeitdauer der Spitzenlasten zu deaktivieren.
9. Echtzeitanalysen mit verteiltem SQL umsetzen
Verteiltes SQL ist nicht spezialisiert auf analytische Abfragen. Trotzdem sind in bestimmten Szenarien Echtzeitanalysen auch mit verteiltem SQL möglich. Wer als Unternehmen diesen Bedarf hat und nicht zusätzlich eine zweite Datenbank nutzen möchte, sollte seine Anwendungsszenarien genau prüfen und die Möglichkeiten von verteiltem SQL bewerten.
Neue Versionen von verteiltem SQL wie Xpand 6.0 oder höher kennen spaltenbezogene Indizes, die Echtzeitanalysen ermöglichen. Ein Spaltenindex wird genutzt, um Datenbankzeilen anhand eines bestimmten Spaltenwertes schnell zu finden. In der Praxis helfen spaltenbezogene Indizes, bestimmte Datentypen schneller zu finden als mit einem herkömmlichen Index. Der Geschwindigkeitsvorteil von Spaltenindizes zeigt sich allerdings erst bei großen Datenmengen.
Spaltenbezogene Indizes lassen sich mit der üblichen Syntax erzeugen, es muss lediglich das Schlüsselwort "columnar" vorangestellt werden. Ein Beispiel:
CREATE COLUMNAR INDEX (column1, column2, column3)
Die Reihenfolge der Spalten ist für einen spaltenbezogenen Index nicht von Bedeutung. Allerdings ist nur ein spaltenbezogener Index pro Tabelle möglich. Er sollte also alle Spalten einschließen, die für diese Art von Index sinnvoll sind. Der Spaltenindex erscheint in der Liste aller Indizes und kann wie gewöhnlich mit
ALTER TABLE DROP INDEX
oder
DROP INDEX
entfernt werden.
10. Verteiltes SQL mit begrenzten IT-Ressourcen nutzen
Verteiltes SQL stellt höhere Anforderungen an die Ressourcen als eine herkömmliche Client-Server-Datenbank. Zwar gibt es mit MaxScale und dem Rebalancer Automatisierungsfunktionen, doch trotzdem ist der administrative Aufwand größer und vor allem schlechter kalkulierbar. Eine einfach zu bedienende Alternative ist SkySQL. Mit dieser Datenbank-as-a-Service (DBaaS) können Unternehmen verteiltes SQL, Columnstore-Analysedatenbanken und MariaDB-Enterprise-Server-Datenbanken bereitstellen und verwalten. Die Vorteile sind eine erweiterte Sicherheit, gegebenenfalls die größere Bandbreite oder die höhere Verfügbarkeit der Cloud. Das System lässt sich zudem leicht skalieren und wird nach den genutzten Leistungen ("Pay per Use") bezahlt.
Der Service bietet beispielsweise ein Failover über mehrere Zonen, Lastausgleich, Ende-zu-Ende-Verschlüsselung und Fähigkeiten zur Selbstheilung nach Störungen. Ein Standardmerkmal der Cloud ist ebenfalls für geschäftskritische Anwendungen wichtig: Das Datenbankmanagementsystem (DBMS) läuft jederzeit in der neuesten Version. Alle Funktions- und Sicherheitsaktualisierungen werden automatisch vom Anbieter ausgebracht. Unternehmen erhalten damit eine schnelle und einfache Kontrolle über die Datenbank, eine integrierte Hochverfügbarkeit und einen klaren Einblick in die Leistung und Verwaltung des DBMS.
Weitere Informationen und Tipps rund um die Nutzung von verteiltem SQL finden Sie im E-Book "Distributed SQL for Dummies" von MariaDB [2].
