Über unsMediaKontaktImpressum
[Sponsored Post] 29. November 2022

Was versteht man unter verteiltem SQL?

Eine Evolution der Datenbank

Bei einem Wechsel in die Cloud stellen Unternehmen schnell fest, dass die klassischen relationalen Datenbanken, auf denen ihre wichtigsten Anwendungen laufen, die Vorteile der Cloud nicht zu nutzen wissen und schlecht zu skalieren sind. Aus diesem Grund sind viele Unternehmen auf der Suche nach der Zuverlässigkeit eines erprobten relationalen Datenspeichers wie Oracle, SQL Server, Postgres und MySQL, wollen aber gleichzeitig die Vorteile in Sachen Skalierbarkeit, Hochverfügbarkeit und globaler Abdeckung einer Cloud.

Einige dieser Unternehmen haben sich für NoSQL-Lösungen entschieden, um ihre Anforderungen erfüllt zu wissen. Diese Alternativen bieten zwar in der Regel den Vorteil der Skalierung und Hochverfügbarkeit, sind allerdings als Transaktionsdatenbank mangelhaft, da sie nicht von Grund auf für diesen Zweck und für wahre Konsistenz konzipiert worden sind. In der jüngeren Vergangenheit haben einige der NoSQL-Lösungen sogenannte "ACID-Transaktionen" ergänzt. Leider stecken diese Notlösungen jedoch voller Probleme und versagen bei der Bereitstellung von Isolationsstufen, welche für geschäftskritische Workloads wie Finanzbücher, Bestandskontrollen und Identitätsmanagements erforderlich sind.

Verteiltes SQL ist eine neue Art von Datenbank.

Einige der erfolgreichsten weltweit agierenden Unternehmen haben dieses Problem gelöst, indem sie speziell für diesen Zweck eigene Datenbanken entwickelt haben. Das bekannteste Beispiel ist Google Cloud Spanner [1]. Im Jahr 2012 veröffentlichte Google eine Studie über Spanner, die eine neue Sichtweise auf Datenbanken demonstrierte, welche auf verteilten Systemen und globaler Skalierung basierten.

"Spanner ist eine skalierbare, multiversionsfähige, weltweit verteilte und synchron replizierte Datenbank von Google. Es ist das erste System, das Daten auf weltweiter Ebene verteilt und extern konsistente verteilte Transaktionen unterstützt." [2]

Sowohl in der Beschreibung als auch in dem 14-seitigen Papier wird darauf eingegangen, wie Google eine konsistente und zugleich skalierbare Datenbank aufbauen konnte. Das Papier skizziert auf geniale Weise die Grundlage der nächsten Evolution der Datenbank: Verteiltes SQL. Verteiltes SQL ist eine einzelne logische Datenbank, die auf mehreren physischen Knoten in einem einzelnen Rechenzentrum oder bei Bedarf in mehreren Rechenzentren bereitgestellt wird. All dies ermöglicht eine reibungslose Skalierung bei gleichzeitiger Widerstandsfähigkeit und Robustheit.

Was ist eine verteilte SQL-Datenbank?

Es gab mehrere Versuche, skalierbares SQL in einer verteilten Umgebung bereitzustellen. Bei einigen dieser Versuche wurden vorhandene Datenbanken nachgerüstet, um den Anforderungen gerecht zu werden. Allerdings kann dies wohl kaum als eine verteilte SQL-Datenbank angesehen werden. Woraus besteht also eine verteilte SQL-Datenbank? Die Anforderungen lassen sich in fünf Rahmenbedingungen zusammenfassen:

1. Skalierbarkeit

Eine verteilte SQL-Datenbank muss reibungslos skalieren können, um den Features von Cloud-Umgebungen gerecht zu werden, ohne jedoch mit zusätzlicher Komplexität für den Betrieb einherzugehen. So wie wir die Rechenleistung ohne großen Aufwand hochskalieren können, sollte auch die Datenbank skalierbar sein. Dazu gehört die Möglichkeit, Daten gleichmäßig auf mehrere verteilte Teilnehmer in der Datenbank zu verteilen.

2. Konsistenz

Eine verteilte SQL-Datenbank muss in einer verteilten Umgebung ein hohes Maß an Isolation bieten. In einer cloud-basierten Welt mit verteilten Systemen und Microservices als Standard-Architektur wird die Konsistenz von Transaktionen zum Problem, da mehrere Bediener versuchen werden, an denselben Daten zu arbeiten. Die Datenbank sollte Konflikte lösen und das gleiche Maß an Isolation von Transaktionen bieten, wie wir es von einer Einzelinstanz-Datenbank kennen.

3. Belastbarkeit

Eine verteilte SQL-Datenbank muss das höchste Maß an Ausfallsicherheit bieten, ohne dass hierfür externe Tools erforderlich werden. Die Cloud stellt eine ständig aktive Umgebung für Workloads dar, sodass die Datenbank die gleichen Eigenschaften haben sollte. Eine verteilte Datenbank kann die Zeit, die für die Wiederherstellung nach einem Ausfall benötigt wird, auf nahezu Null reduzieren und Daten auf natürliche Weise ohne externe Konfiguration replizieren.

Die Datenbank sollte Ihre Anwendungen nicht hindern sondern Ihre Erwartungen erfüllen.

4. Geo-Replikation

Eine verteilte SQL-Datenbank sollte die Verteilung von Daten in einer komplexen, weit verstreuten geographischen Umgebung ermöglichen. Die Cloud bietet die Möglichkeit, jeden Winkel der Welt mit einer akzeptablen Servicequalität zu erreichen. Die Datenbank sollte Ihre Anwendungen nicht daran hindern und stattdessen Ihre Erwartungen erfüllen.

5. SQL

Obwohl die oben erwähnten vier technischen Anforderungen von größter Bedeutung sind, gibt es vor allem eine wichtige Voraussetzung. Die Datenbank muss SQL sprechen. Es ist die Sprache der Daten und der Standard für die gesamte Anwendungslogik. Wir sollten Entwickler nicht umschulen müssen, um die Datenbank zu verwenden. Sie sollten in der Lage sein, mit dem bereits vertrauten SQL arbeiten zu können.

Einige Datenbanken erfüllen diese Anforderungen bereits. Dazu gehören natürlich Spanner, aber auch Amazon Aurora, Yugabyte, FaunaDB und CockroachDB. Alle diese Optionen erfüllen die Anforderungen in einer gewissen Art und Weise, wobei einige Optionen besser sind als andere. Was fällt auf? Es fehlen Oracle, Postgres, MySQL und alle NoSQL-Optionen. Sie sind leider nicht in der Lage, alle fünf erwähnten Rahmenbedingungen zu erfüllen und können daher nicht als Alternative betrachtet werden.

In diesem Video möchte ich kurz auf diese Prinzipien zu sprechen kommen:

In seinem Webinar "Erste Schritte mit CockroachDB - Binary, Docker und Kubernetes" erklärt Patrick Schulz die ersten Schritte mit CockroachDB und die beliebtesten Deployment-Methoden, eine verteilte Datenbank auszurollen: Binary, Docker und Kubernetes.

Das Webinar ist ideal für Entwickler, welche erste Schritte mit einer verteilten SQL-Datenbank gehen möchten. Nach diesem Webinar werden Sie in der Lage sein, CockroachDB lokal auszurollen. 

>> zum Webinar

Verteilte SQL-Datenbanken müssen Datenlokalität bieten

Wird eine verteilte Umgebung zum Standard, wird es schnell offensichtlich, dass Datenbanken die Domizilierung von Daten übernehmen könnten. Da sich die Teilnehmer in verschiedenen Regionen befinden oder verschiedene Rechenzentren nutzen, können die jeweiligen Standorte nachvollzogen und die dort gespeicherten Daten mit einem Standort verknüpft werden. Bei einigen Anwendungen ist dies bereits implementiert, doch leider ist dieser Ansatz sehr fehleranfällig. SQL sieht sich der neuen Herausforderung gegenübergestellt, Datenbanken anhand von einem Feld in der Tabelle zur Geopartitionierung von Daten zu verwenden. Die Datenbank könnte so Bedenken hinsichtlich der Datenhoheit ausräumen. Außerdem wäre es möglich, bestimmten Benutzern anhand der Daten zu folgen, um den Zugriff auf deren Informationen mit geringer Latenz sicherzustellen oder um Daten an eine explizite Cloud zu binden, um wiederum die Kosten für den ausgehenden Datenverkehr zu reduzieren.

Gute verteilte SQL-Datenbanken müssen multi-cloud-fähig sein

Verteilte SQL-Datenbanken sind in dem Sinne einzigartig, als dass sie über halbautonome Einheiten verfügen, die alle Teile eines größeren Systems sind. Jede Einheit sollte in der Lage sein, einzeln genutzt zu werden und sich dann dem größeren System (z. B. dem CockroachDB-Cluster) anzuschließen. Diese Eigenschaft ist der Grundstein, um die fünf oben aufgeführten Anforderungen zu erfüllen. Sie kann auch genutzt werden, um die Datenbank zu einer echten Multi-Cloud-Datenbank zu erweitern. Die Datenbank sollte sich nämlich nicht auf ein einziges Netzwerk verlassen müssen, um die gewünschte Verteilung zu erreichen. Stattdessen sollten sich Teilnehmer überall befinden können, egal ob in einer öffentlichen Cloud, einer privaten Cloud oder sogar in einer einzelnen Instanz vor Ort. Diese Anforderung ist wichtig für die Zukunft der Datenverarbeitung, da wir in einer verteilten Hybrid- und Multi-Cloud-Welt leben werden.

Grundlegende Anforderungen für verteiltes SQL

Die oben genannten Anforderungen beziehen sich natürlich auf verteiltes SQL, allerdings sollte beachtet werden, dass es sich immer noch um eine Datenbank handelt. Als solche muss sie die grundlegenden Anforderungen erfüllen, die da wären:

1. Administration: Nutzer sollten in der Lage sein, die Datenbank anhand einer Reihe von befehlszeilen- und grafik-basierten Tools unkompliziert und reibungslos zu installieren und zu konfigurieren. Darunter verstehen wir auch die Möglichkeit zur Kontrolle der Umgebung und des Datenlebenszyklus zum Zweck der Sicherung/ Wiederherstellung sowie die Möglichkeit, Tabellen zu erstellen, Schemata zu definieren und zu implementieren, Indizes/ Partitionen festzulegen und die DDL neu zu erstellen.

2. Optimierung: Ein DBA sollte mit der Datenbank Einblicke in die Performance von Querys gewinnen und diese optimieren können. Dazu gehören ausgeklügelte Features wie ein kostenbasierter Optimierer, der in einer verteilten Welt nicht wegzudenken ist.

3. Sicherheit: Wie bei jeder Software-Lösung für Unternehmen steht die Sicherheit an erster Stelle. Die Datenbank sollte die wichtigsten Features im Sinne der Vertraulichkeit, Integrität und Verfügbarkeit bieten. Gleichzeitig sollte sie nicht getrennt agieren, sondern zusammen zum Zweck des Identitätsmanagements und der Governance mit bestehenden Systemen interagieren, sodass konsistente Richtlinien für die darin enthaltenen Daten (auf Tabellen-, Zeilen- und Spaltenebene) festgelegt werden können.

4. Integration: Eine Datenbank kann nicht ohne erprobte oder bekannte Treiber in Ihre bestehenden Anwendungen integriert werden. Selbstverständlich sollte die Datenbank sich gut in bestehende ORMs integrieren lassen und auch die Möglichkeit zum Massen-Import oder -Export bieten. Des Weiteren sollte sie mit ETL-Tools arbeiten können und Datenerfassungsfunktionen bieten, um mit fortschrittlichen Diensten wie Streaming-Analysen oder Cloud-Speicher integriert werden zu können.

Diese "grundlegenden" Anforderungen sind entscheidend und lassen auf eine ausgereifte Datenbank schließen, die für Unternehmen geeignet ist. Es mögen vielleicht nicht die aufregendsten Features sein, aber sie sind von grundlegender Bedeutung für den Erfolg eines jeden Projekts.

So bewerten Sie verteilte SQL-Datenbanken

CockroachDB ist eine ideale Wahl für Ihre cloud-native verteilte SQL-Datenbank. Diese Option hat bereits Hunderten von Unternehmen dabei geholfen, sowohl die alltäglichen Arbeiten als auch einige der kritischsten Aufgaben des Betriebs in die Cloud zu verlagern. Selbst in komplexeren Umgebungen hat sich diese Option als gute Grundlage für eine cloud-native Strategie erwiesen.

Wir sind Befürworter dieser aufstrebenden Nische und sind der festen Überzeugung, dass verteiltes SQL die richtige Weiterentwicklung der Datenbank ist und die Zukunft sein wird, wie wir Daten in der Cloud verwalten. Aus diesem Grund gehen wir davon aus, dass unsere und alle anderen Lösungen höchsten Wert auf diese Kernanforderungen legen sollten:

  1. Skalierung
  2. Konsistenz
  3. Widerstandsfähigkeit
  4. Geo-Replikation
  5. SQL
  6. Lokalität
  7. Multi-Cloud
  8. Administration
  9. Optimierung
  10. Sicherheit
  11. Integration

Jene Datenbank, die all diese Anforderungen erfüllt, kann für die unternehmenskritischen (und auch nicht so unternehmenskritischen) Anwendungen in der Cloud verwendet werden. Einige dieser Anforderungen sind recht anspruchsvoll. Es handelt sich um komplexe Themen, die viel Zeit erfordern. Befassen Sie sich unbedingt mit Konzepten wie der Konsistenz oder der Lokalität, wenn Sie diese Punkte mit Ihrem Anbieter besprechen. Zwar haben alle die gleiche theoretische Grundlage, aber letztendlich kommt es immer auf die Implementierung und vor allem auf die tatsächliche Verwendung an. Wie bei jeder neuen Kategorie werden die komplexen Probleme und Bugs erst in der Verwendung offensichtlich und können erst dann behoben werden. Die zwölfte (und damit letzte) Anforderung ist daher die "Maturity".

Autor

Patrick Schulz

Patrick ist ein IT-Experte mit über 15 Jahren Erfahrung im Bereich Private- und Public-Cloud-Technologien. Er hat mit zahlreichen Unternehmen an Cloud-Projekten zusammengearbeitet.
>> Weiterlesen
Das könnte Sie auch interessieren
Kommentare (0)

Neuen Kommentar schreiben