Verteiltes SQL ist eine vielversprechende Alternative zu herkömmlichen Client-Server-Datenbanken. Doch es eignet sich nicht für alle Szenarien. Unternehmen sollten bei der Entscheidung für oder gegen eine bestimmte Lösung einige Kriterien beachten.
Verteilte SQL-Datenbanken verwenden dasselbe relationale Modell und dieselbe Abfragesprache wie traditionelle Datenbanken. Sie verteilen jedoch Lese- und Schreibvorgänge, die Verarbeitung von Abfragen und die Indizierung auf einen Cluster von Datenbankknoten.
Verteilte Datenbanken sind sinnvoll, wenn die Arbeitslast die Kapazität eines einzelnen Servers übersteigt, da sie Daten in einer angemessenen Zeit zurückgeben können. Sie zeichnen sich durch eine hohe Verfügbarkeit aus, steigern die Gesamtkapazität und optimieren die Skalierung des Datenbanksystems.
Kriterien für die Auswahl einer Datenbanklösung
Die Einführung einer Datenbanklösung auf der Basis von verteiltem SQL ist allerdings kein Selbstläufer. Auf dem Markt finden sich vielfältige Lösungen, die sich nicht für jedes Anwendungsszenario eignen. Im Vorfeld müssen Fragen geklärt werden, beispielsweise die Übereinstimmung mit den Anforderungen an Latenzen und Datendurchsatz. Die folgende Übersicht nennt Kriterien, mit denen Unternehmen das Marktangebot prüfen können.
Database as a Service (DBaaS)
Viele Anbieter von verteilten SQL-Systemen vertreiben ihr Produkt auch als Database as a Service (DBaaS). Hier empfiehlt sich ein genauer Blick auf das Angebot: Nicht alle sind über das Teststadium hinaus voll funktionsfähig oder verfügen über öffentliche Referenzen von Produktivsystemen.
Verfügbarkeit von Cloud-Anbietern
Unternehmen können ihre verteilten SQL-Datenbanken selbst verwalten, entweder im eigenen Rechenzentrum oder bei einem beliebigen Cloud-Dienst. Wenn es jedoch darum geht, die Kubernetes-Implementierung eines bestimmten Cloud-Anbieters zu unterstützen oder DBaaS zu nutzen, gibt es unterschiedliche Möglichkeiten. Eine flexible Lösung unterstützt alle drei großen Cloud-Plattformen (AWS, Google, Azure) für selbst gehostete Installationen.
Private & Hybrid Clouds
Viele IT-Organisationen betreiben aus Gründen der Sicherheit oder der Netzwerklatenz zusätzlich zu externen Cloud-Diensten auch Private Clouds. So arbeiten beispielsweise IT-Systeme in der Industrieproduktion in der Regel lokal und nutzen die Cloud für die Notfallwiederherstellung. Einige Angebote von verteiltem SQL sind aber nur im Public-Cloud-Format verfügbar. Wichtiges Auswahlkriterium ist deshalb die Verfügbarkeit in öffentlichen, privaten und hybriden Clouds.
Datendurchsatz
Ein wichtiger Grund für das Nutzen von verteiltem SQL ist letztlich ein höherer Durchsatz bei geringeren Kosten. Bei jeder Plattform gibt es unterschiedliche Möglichkeiten und Einschränkungen. Einige der weltweit größten Unternehmen setzen verteiltes SQL mit bis zu 120.000 Transaktionen pro Sekunde (TPS) ein. Solche Werte sind mit herkömmlichen Datenbanken nur schwer zu erreichen. Allerdings bietet auch nicht jeder Anbieter von verteilten SQL-Systemen diese Leistung.
Skalierbarkeit
Fast alle Datenbanken sind in gewissem Maße skalierbar. Verteilte SQL-Datenbanken sind deutlich besser skalierbar als traditionelle Datenbanken oder viele NoSQL-Datenbanken wie MongoDB. Unternehmen sollten Benchmarks nutzen, um die Skalierbarkeit unterschiedlicher Datenbanksysteme zu vergleichen. Ein wichtiges Kriterium ist dabei die Möglichkeit, Cluster automatisch und ohne Daten- oder Dienstverlust zu verkleinern, indem Knoten entfernt werden.
Latenzen
Eine verteilte Datenbank hat eine höhere Latenz als eine lokale Festplatte oder eine Client-Server-Datenbank. Trotzdem sollte sie eine Latenz von mindestens zehn Millisekunden bieten, selbst bei Tausenden oder Hunderttausenden von Anfragen pro Sekunde.
Um die richtige Lösung für verteiltes SQL auszuwählen, müssen Unternehmen die gesamte Antwortzeit als Zeitbudget betrachten. Entscheidend ist die Wartezeit zwischen einem Benutzerklick und der Ankunft der Daten, einschließlich HTML, Grafiken, JSON und anderer Komponenten. Bei alltäglichen Anwendungen sollten Unternehmen mit einer Antwortzeit von drei Sekunden rechnen. Bei Echtzeit-Anwendungen im E-Commerce wird das Budget eher bei einigen Dutzend Millisekunden liegen.
Die Datenbanklösung selbst sollte nur einen Bruchteil des gesamten Zeitbudgets verbrauchen, damit sie nicht zu einem Nadelöhr wird. Diese Abschätzung der notwendigen Latenz aufgrund der tatsächlichen Anforderung einer Anwendung ist ein wichtiges Beurteilungskriterium für verteiltes SQL.
Verfügbarkeit
Verteilte SQL-Datenbanken bieten eine hohe Ausfallsicherheit, die bei einfachen Client-Server-Datenbanken nicht möglich ist. Besonders hoch ist die Ausfallsicherheit in der Cloud. So kann beispielsweise eine ganze Verfügbarkeitszone ohne Ausfall des Datenbankdienstes verloren gehen.
Kompatibilität
Eine entscheidende Frage bei der Auswahl einer verteilten SQL-Datenbank ist der Aufwand für die Migration bestehender Anwendungen. Verschiedene Lösungen unterstützen unterschiedliche SQL-Dialekte, Datentypen und Semantiken. Die beste Lösung ist hier üblicherweise, innerhalb einer Datenbankfamilie zu bleiben – also beispielsweise von der Client-Server-Edition einer Datenbank zur DBaaS-Variante zu wechseln.
Bei SQL-Anwendungen, die für andere Datenbanken geschrieben wurden, ist der Aufwand in etwa so groß wie der Wechsel zu einem anderen RDBMS. Unter anderem müssen die Abfragen sowie die in SQL-DDL-Anweisungen verwendeten Typnamen geändert werden.
Kosten
Ein Kostenvergleich unterschiedlicher Lösungen sollte die Aufwendungen für Lizenzen, Cloud-Ressourcen, das Risiko von Ausfällen, Mitarbeiterschulungen und die allgemeine Wartung berücksichtigen. Ohne Berücksichtigung weiterer Kriterien ist ein DBaaS-Angebot meist kosteneffizienter, unter anderem durch verbrauchsabhängige Bezahlung.
Doch manche Unternehmen haben das Problem der irreversiblen Kosten durch Bestandsysteme, die aus unterschiedlichen Gründen nicht abgelöst werden können. In diesem Fall ist die Bereitstellung einer Datenbank vor Ort die bessere Wahl.
Vor der Kaufentscheidung: der Machbarkeitsnachweis
In den meisten Fällen werden anhand der oben genannten Kriterien vielleicht noch zwei oder drei Datenbanksysteme übrigbleiben. Selbst wenn es nur eines ist: Unternehmen sollten auf jeden Fall die Eignung für ihre spezifischen Zwecke in ausführlichen Tests überprüfen. Dafür bieten die meisten Anbieter zeitlich limitierte Testversionen oder Testzugänge an.
Der wichtigste Aspekt bei der Entwicklung eines Machbarkeitsnachweises besteht darin, sich auf alltagstaugliche Daten und Abfragen zu konzentrieren. Es ist wenig sinnvoll, die Grenzen einer Plattform mit unrealistischen Abfragen zu testen – etwa 15 Joins mit 6 Tabellen. Sie sind für typische Datenbanktransaktionen nicht aussagekräftig.
Datenbanktechnologien gehen immer Kompromisse ein und sind für bestimmte Nutzungsmuster optimiert. Bei verteiltem SQL ist das der Durchsatz des Transaktionsvolumens. Beim Entwurf eines Machbarkeitsnachweises sollte also der tatsächliche Produktionsdaten- und Anwendungsverkehr genutzt werden. Am zweitbesten ist eine Simulation mit einem Testsystem, die dem üblichen Nutzungsmuster bei Tabellenstruktur, Abfragekomplexität und Anteil der Lese- und Schreibvorgänge nahekommt.
Die Tests sollten über die Messung einzelner Faktoren wie Datenbanklatenz hinausgehen. So ist es hilfreich, die Gesamtleistung der Anwendung bei Nenn- und Spitzenlasten zu bewerten und dabei die Spreizung der Latenzwerte zu beachten. Zudem muss bei den Tests sichergestellt werden, dass die Infrastruktur eine ausreichende Last erzeugen kann, damit sie nicht zum Nadelöhr wird und den Test verfälscht.
Am Ende der Tests steht dann eine Entscheidung: verteiltes SQL ist eine gute Option für Systeme, die ein hohes Datenvolumen, eine große Anzahl von Nutzern oder hohe Anforderungen an die Verfügbarkeit und die Notfallwiederherstellung haben. Darüber hinaus eignen sie sich besonders für Systeme, die in die Cloud migriert werden.
