Seit mindestens drei Jahrzehnten sind Datenbanksysteme eine wichtige Komponente der Innovation in Unternehmen. Das gilt für jede Branche und jede Firmengröße. Denn das weltweite Datenvolumen wächst stark, immer mehr digitale Anwendungen produzieren Daten in großen Mengen. Nach aktuellen Schätzungen liegt das globale Datenvolumen bei mindestens 59 Zettabyte, Tendenz steigend.
Der Grund für dieses Wachstum ist der Wandel der Arbeitsweise in den Unternehmen. Sie ermitteln immer mehr Daten aus Kunden- und Warenbewegungen, vernetzten Maschinen und Anlagen, sozialen Medien und vielem mehr. Nicht nur das stetige Anwachsen der Datenmengen, sondern auch die zunehmende Globalisierung stellt Datenbanken vor neue Herausforderungen. Denn Kunden sind weltweit verteilt und Unternehmen benötigen Datenbanken, die rund um die Uhr Spitzenlasten abarbeiten können.
Die Grenzen herkömmlicher SQL-Datenbanken
Standard sind immer noch relationale Datenbankmanagementsysteme (RDBMS), da diese sehr zuverlässig arbeiten sowie eine hohe Konsistenz und Datenintegrität gewährleisten. Das Modell stammt ebenso wie die Datenbank-Abfragesprache SQL (Structured Query Language) aus den 1970er-Jahren. Beide Konzepte sind so stark verknüpft, dass häufig von SQL-Datenbanken die Rede ist, wenn RDBMS gemeint sind.
Herkömmliche SQL-Datenbanken sind an ihre Grenzen gestoßen, weil sie das Wachstum digitaler Unternehmen, die auf Skalierbarkeit angewiesen sind, nicht unterstützen. Deshalb nutzen die Unternehmen eine ganze Reihe unterschiedlicher technischer Lösungen. Eine Möglichkeit, Datenbankzugriffe zu skalieren, ist das Konzept des Sharding oder der Partitionierung.
Dabei wird ein einziger logischer Datensatz aufgeteilt und in mehreren Datenbanken gespeichert, um die Gesamtkapazität zu erhöhen und zusätzliche Anfragen zu bearbeiten. Die Umsetzung von Sharding ist jedoch nicht so einfach. Der Ansatz ist komplex, schwer zu warten und verursacht hohe technische Kosten. Letztlich erlaubt die Partitionierung nur begrenzte Transaktionen und bringt Einschränkungen bei Abfragen mit sich.
NoSQL: Skalierbare Alternative mit Nachteilen
Vor etwa zehn Jahren bildete sich eine leistungsfähige Alternative: NoSQL (Not only SQL). Dieses Kürzel bezeichnet Datenbanken, die einem nicht-relationalen Ansatz folgen. Sie benötigen keine festgelegten Tabellenschemata und sind einfacher zu skalieren als relationale Systeme. Deshalb sind sie optimiert für moderne Anwendungen, die sehr große Volumina unterschiedlicher Datentypen nutzen, beispielsweise im industriellen Internet der Dinge.
Dieser Ansatz beseitigt zwar einige Probleme von RDBMS, hat aber seinen Preis. NoSQL bedeutet den Verzicht auf einige Vorteile relationaler Datenbanken. Dazu gehören beispielsweise die Datenintegrität und die Möglichkeit, ACID-Transaktionen zu nutzen – atomare, konsistente, isolierte und dauerhafte Datenbanktransaktionen.
Dies kann dazu führen, dass die Daten inkonsistent werden, Transaktionen sich gegenseitig beeinflussen oder sie nicht dauerhaft gespeichert werden können. Zusammen mit der hohen Komplexität der Datenmodellierung sowie der Notwendigkeit spezieller Werkzeuge erschwert das den Einsatz in herkömmlichen Szenarien.
Verteiltes SQL wird nicht zum Flaschenhals
Eine Alternative zu diesen beiden Technologien ist verteiltes SQL. Dahinter verbirgt sich eine relationale Datenbankarchitektur, bei der mehrere Instanzen („Knoten“) des Datenbanksystems gleichzeitig und unabhängig voneinander arbeiten. Sie können sich in einem oder in mehreren Rechenzentren befinden. Das System verteilt automatisch neue und veränderte Daten sowie Abfragen auf diese Instanzen, sorgt für einen Lastausgleich und synchronisiert die Datenbankinhalte.
Dadurch wird ein einzelner Knoten nicht zu einem Engpass, hohe Leistung und Verfügbarkeit sind die Folge. Abfragen wiederum verteilt das System automatisch auf mehrere Knoten, sodass auch hier kein Flaschenhals entsteht. Ein weiterer Vorteil: Verteilte Datenbanken sind leicht skalierbar, denn bei Bedarf können beliebig viele Knoten hinzugefügt oder entfernt werden.
Dabei wird das Gesamtsystem als sogenannte „Shared-Nothing-Architektur“ gestaltet: Die einzelnen Knoten arbeiten unabhängig voneinander. Der Ausfall eines Knotens hat keine Auswirkung auf die anderen. Die restlichen bearbeiten alle Lese- und Schreibzugriffe wie gewohnt weiter. Sobald der Knoten wieder verfügbar ist, sorgt das DBMS automatisch dafür, dass Änderungen an den Daten auf allen Systemen synchronisiert werden.
Hochverfügbarkeit und einfache Nutzung
Eine verteilte SQL-Datenbank ist durch ihre hohe Ausfallsicherheit anderen Datenbankarchitekturen überlegen. Zudem bieten die Systeme alle wichtigen Merkmale des relationalen Modells sowie die gewohnte Standard-Datenbanksprache. Dadurch ist die Einführungsphase von verteiltem SQL kurz: Sämtliche Grundfunktionen einschließlich der Abfragesyntax sind kompatibel zu bekannten Systemen wie MariaDB, MySQL oder PostgreSQL. Und natürlich enthält verteiltes SQL alle Funktionen, die relationale Datenbanken so leistungsfähig machen, etwa JOINs und ACID-Konformität.
Eine einheitliche Datenbankoberfläche mit Webschnittstelle sorgt zudem dafür, dass Administratoren und Profianwender ihre gewohnten Arbeitsroutinen und Skripte nutzen können. Und darüber hinaus sind DBMS für verteiltes SQL leicht in typische Geschäftsanwendungen zu integrieren: Über eine in das DBMS integrierte Schnittstelle greifen sie darauf wie auf eine herkömmliche Einzeldatenbank zu.
Die unbegrenzte Skalierbarkeit in beiden Richtungen gilt für Cluster mit nur drei Knoten ebenso wie für Installationen mit Hunderten oder sogar Tausenden von Knoten. Große Cluster sind in der Lage, Dutzende Millionen von Abfragen pro Sekunde zu verarbeiten, ohne dass die Datenintegrität oder die Verfügbarkeit beeinträchtigt wird. So ist verteiltes SQL die ideale Lösung für alle Unternehmen, die kontinuierliche Hochverfügbarkeit ihrer Datenbanken benötigen.
Neueste Kommentare
Noch keine Kommentare zu Verteiltes SQL: Hochverfügbarkeit für Unternehmen
Kommentar hinzufügenVielen Dank für Ihren Kommentar.
Ihr Kommentar wurde gespeichert und wartet auf Moderation.