Verteiltes SQL Kriterien für die Auswahl der richtigen Datenbank

Anbieter zum Thema

PANDUIT

Rittal GmbH & Co. KG

Fsas Technologies GmbH

Wenn Client-Server-Datenbanken an Grenzen stoßen, sollten Unternehmen ihren Ersatz durch verteiltes SQL planen. Doch nicht jedes System eignet sich für jedes Szenario. Deshalb sind bei der Auswahl der richtigen Lösung einige Kriterien zu beachten.

Datenbanktechnologien sind immer ein Kompromiss und für bestimmte Nutzungsmuster optimiert. Mal stehen schnelle Abfragen, mal die Speicherung großer Datenmengen im Vordergrund. Wenn die typische Arbeitslast im Betriebsalltag die Kapazität eines einzelnen Servers mit einem relationalen Datenbanksystem überschreitet, ist Abhilfe nötig.

Dabei müssen Unternehmen nicht das bewährte relationale Modell und die Abfragesprache SQL aufgeben, verteilte SQL-Datenbanken sind eine Alternative. Sie erhalten das Bewährte, verteilen jedoch Lese- und Schreibvorgänge, die Verarbeitung von Abfragen und die Indizierung auf einen Cluster von Datenbankknoten. Die Cluster besitzen eine hohe Verfügbarkeit, steigern die Gesamtkapazität und optimieren die Skalierung.

Die optimale Datenbanklösung finden

Viele Datenbankanbieter haben verteiltes SQL im Portfolio, so dass der Marktüberblick nicht leicht zu gewinnen ist. Unternehmen sollten deshalb die Einführung einer entsprechenden Lösung genau planen und ihre Anforderungen berücksichtigen. Nicht jedes Datenbanksystem unterstützt jedes Anwendungsszenario. Besonders wichtig sind die Anforderungen an Latenz und Datendurchsatz. Die folgenden Abschnitte enthalten eine Reihe von Fragen, mit deren Hilfe Unternehmen die Auswahl der am besten geeigneten Datenbank vereinfachen können.

Lässt sich die Datenbank einfach skalieren?

Die Skalierung der Leistung ist bei jedem Datenbanksystem möglich – in einem bestimmten Rahmen. Normalerweise ist verteiltes SQL deutlich besser skalierbar als RDBMS oder NoSQL-Datenbanken. Unternehmen sollten hier zu Benchmarks greifen, um die von ihnen betrachteten Systeme zu vergleichen. Entscheidend ist das automatische Entfernen von Knoten aus einem Cluster, ohne dass es durch diese Verkleinerung zu einem Daten- oder Dienstverlust kommt.

Welche Verfügbarkeit bietet die verteilte SQL-Datenbank?

Datenbankcluster sind deutlich ausfallsicherer als einfache Client-Server-Systeme. In der Cloud ist die Ausfallsicherheit besonders hoch. Dort kann bei einem Anbieter durchaus eine ganze Verfügbarkeitszone ausfallen, ohne dass der Datenbankdienst offline geht.

Gibt es die Datenbank als Service?

Verschiedene Hersteller von verteilten SQL-Systemen bieten ihre Lösung auch als Database-as-a-Service (DBaaS) an. Unternehmen sollten solche Angebote genau prüfen. Einige befinden sich noch im Teststadium und bieten einen eingeschränkten Funktionsumfang. Hinzu kommt, dass nicht immer Referenzkunden von Produktivsystemen genannt werden.

Kann die Datenbank in der Cloud genutzt werden?

Sollte ein Unternehmen die Verwaltung der verteilten SQL-Datenbanken in Eigenregie bevorzugen, gibt es mehrere Optionen. Möglich ist die Bereitstellung im eigenen Rechenzentrum oder bei einem Cloud-Anbieter. Hier gibt es wiederum zwei Varianten, entweder als Container mit der vom Provider angebotenen Kubernetes-Implementierung oder als DBaaS. Eine variable Lösung unterstützt alle großen Cloud-Plattformen – etwa AWS, Google oder Azure – für eigens gehostete Installationen.

Werden die Konzepte Private und hybride Cloud unterstützt?

Viele Unternehmen fordern für bessere Cyber-Sicherheit oder geringere Netzwerklatenz die Nutzung bestimmter Kernanwendungen in einer Private Cloud. Ein Beispiel dafür ist die Industrieproduktion: Deren IT-Systeme arbeiten häufig lokal, die Cloud wird hier ausschließlich für die Notfallwiederherstellung genutzt. Angebote im Public-Cloud-Format sind hier nur eingeschränkt möglich. Ein entscheidendes Auswahlkriterium ist deshalb, ob die Lösung in öffentlichen, privaten und hybriden Clouds verfügbar ist.

Welche Latenz bietet das System im Produktivbetrieb?

Die für ein bestimmtes Anwendungsszenario notwendige Latenz muss von den Unternehmen zunächst ermittelt werden. Dafür müssen sie die gesamte Antwortzeit zwischen Benutzerklick und Ankunft der Daten, einschließlich JSON, Grafiken, HTML und anderer Komponenten, berücksichtigen. Dies ist das Zeitbudget. Die Datenbank selbst sollte nur einen kleinen Teil davon verbrauchen, damit sie nicht zum Flaschenhals wird. Als Faustregel gilt: Das Datenbanksystem benötigt eine Latenz von mindestens zehn Millisekunden, selbst bei hunderttausenden Anfragen pro Sekunde.

Wie hoch ist der Datendurchsatz?

Eine der größten Vorteile von verteiltem SQL ist der hohe Datendurchsatz bei relativ niedrigen Kosten. Hier bietet jede Lösung unterschiedliche Möglichkeiten, aber auch Einschränkungen. Großunternehmen nutzen häufig Implementierungen von verteiltem SQL mit bis zu 120.000 Transaktionen pro Sekunde (TPS). Herkömmliche Datenbanksysteme sind dazu nicht in der Lage, doch auch nicht jedes verteilte SQL-System auf dem Markt erreicht diesen Durchsatz.

Welchen Aufwand hat die Migration bestehender Anwendungen?

Zur Implementation einer verteilten SQL-Datenbank gehört auch die Migration der Daten. Dafür müssen Unternehmen unterschiedliche Semantiken, Datentypen und SQL-Dialekte berücksichtigen. Der geringste Aufwand entsteht, wenn die Migration innerhalb einer Datenbankfamilie erfolgt – etwa beim Wechsel von einer Client-Server-Edition zur DBaaS-Variante. Zudem hat die Übertragung von SQL-Anwendungen einen gewissen Aufwand. In aller Regel müssen Abfragen und die Typnamen in SQL-DDL-Anweisungen geändert werden.

Welche Gesamtkosten hat die Datenbanklösung?

Beim Vergleich der Gesamtkosten einer verteilten SQL-Datenbank (TCO, Total Cost of Ownership) ist es sinnvoll, neben Lizenzkosten auch Aufwendungen wie Cloud-Ressourcen, Maßnahmen gegen Ausfallrisiken, Mitarbeiterschulungen und die Wartung einzubeziehen. Grundsätzlich ist ein DBaaS-Angebot kosteneffizienter, da vor allem die verbrauchsabhängige Bezahlung günstiger ist als die Kombination aus Nutzerlizenzen und eigenen IT-Ressourcen. Allerdings gibt es in vielen Unternehmen Altsysteme, die nicht ohne weiteres abgelöst werden können. Hier ist eine lokale Lösung meist die bessere Wahl.

Diese Kriterien erlauben Unternehmen eine fundierte Entscheidung. Verteiltes SQL ist eine gute Option für Systeme mit einer großen Anzahl von Nutzern, einem hohen Datenvolumen, oder hohen Ansprüchen an die Notfallwiederherstellung und die Verfügbarkeit. Zudem eignet sich die Technologie besonders für Systeme, die in die Cloud migriert werden.

* Der Autor: Andrew Oliver ist Senior Director of Product Marketing bei der MariaDB Corporation, einem führenden Anbieter von Cloud-basierten und lokalen Datenbanklösungen. Seit 2021 für MariaDB tätig, verfügt er aus vorherigen Stationen bei IBM, Cisco, Red Hat, Lucidworks, Couchbase und Yugabyte profunde Kenntnisse sowohl in der Java-Entwicklung als auch im Bereich des technischen Produktmarketings.

(ID:47836418)