Datenbanken haben seit den frühen 1980er Jahren einen weiten Weg zurückgelegt und bieten heute einen Varaintenreichtum, in dem Anwender schnell der Überblick verlieren können. Inzwischen lassen sich die Systeme so gut wie überall ausgeführen - vom Smartphone über den Server in Ihrem Rechenzentrum bis hin zu geografisch verteilten Cloud-Instanzen.

Neben den klassischen Tabellen-basierten relationalen Datenbanken gibt es Datenbanken für Zeitreihen-, Diagramm-, Raum-, Text-, OLAP- (Online Analytical Processing), XML- und JSON-Informationen. Einige Datenbanken sind auf bestimmte Arten von Daten spezialisiert, andere bieten eine Auswahl an Datentypen und wieder andere erlauben die Koexistenz mehrerer Datentypen in derselben Datenbankinstanz. Es gibt Graph-Datenbanken, deren Fokus auf den Beziehungen zwischen verschiedenen Datenpbjekten liegt. Einige Datenbanken sind auf die Online-Transaktionsverarbeitung (OLTP) spezialisiert, andere auf die Analyse (OLAP), und wieder andere eignen sich gut für eine Kombination aus Transaktions- und Analyselast. Dieser Artikel konzentriert sich auf Systeme für transaktionale Workloads, die in der Cloud laufen.

Datenbank aus der Cloud - Auswahlkriterien

Eine Datenbank ist keine alleinstehende Entität: In der Regel bildet Sie das Backend oder die Speicherschicht einer Applikation. Um die für Sie passende Cloud-Datenbank auswählen zu können, sollten Sie sich folgende Fragen stellen:

Wie viele Daten erzeugen Sie - und wie schnell?

Kleine Datenmengen, gemessen in Gigabyte oder weniger, können von fast jeder Cloud-Datenbank verarbeitet werden - in einigen Fällen können diese Daten direkt im Arbeitsspeicher verarbeitet werden. Viele Cloud-Datenbanken können Terabytes an Daten verarbeiten - nur einige wenige sind jedoch auch in der Lage, mit Daten im Petabyte-Bereich umzugehen. Beachten Sie, dass bei den meisten Cloud-Datenbanken monatliche Gebühren für den Speicherplatz anfallen. SSD-Speicher ist dabei kostenintensiver als Festplattenspeicher.

Die Geschwindigkeit, mit der die Daten in die Cloud fließen, kann andere Messgrößen wie die Schreibgeschwindigkeit der Datenbank und die Netzwerkkapazität negativ beeinflussen. Wenn viele Daten auf einmal ankommen, muss die Datenbank oder ein Front-End-Programm sie möglicherweise im RAM puffern, um Datenverluste zu vermeiden während sie in den Festspeicher geschrieben werden.

Kennen Sie Ihr Schema schon?

Wenn Ihr Datenbankschema (also die Struktur der Daten) vorgegeben ist, sich im Laufe der Zeit nicht wesentlich ändern wird und Sie möchten, dass die meisten Felder von Datensatz zu Datensatz konsistente Typen aufweisen, dann sind SQL-Datenbanken eine gute Wahl für Sie. Anderenfalls sind NoSQL-Datenbanken, von denen einige nicht einmal Schemata unterstützen, möglicherweise besser für Ihre Anwendung geeignet.

Welche Form passt am besten zu Ihren Daten?

Relationale SQL-Datenbanken wie Microsoft SQL Server oder MySQL, speichern stark typisierte Daten in Tabellen mit Zeilen und Spalten. Sie stützen sich auf definierte Beziehungen zwischen Tabellen, verwenden Indizes, um ausgewählte Abfragen zu beschleunigen und nutzen JOINS, um mehrere Tabellen gleichzeitig abzufragen. Viele moderne relationale Datenbanken unterstützen auch andere Formen.

Dokumentdatenbanken wie MongoDB und Couchbase speichern in der Regel schwach typisierte JSON-Daten (entweder Text oder binär), die Arrays und verschachtelte Dokumente enthalten können. Graph-Datenbanken speichern entweder Scheitelpunkte und Kanten mit Eigenschaften (zum Beispiel Neo4j) oder RDF-Tripel (zum Beispiel AllegroGraph). Unabhängig von der Implementierung legen Graph-Datenbanken den Schwerpunkt auf die Verbindungen zwischen Entitäten. Zu den anderen NoSQL-Datenbankkategorien gehören Key-Value-Datenbanken wie RocksDB und spaltenorientierte Systeme wie Cassandra.

Manchmal sind die Daten in einer Form erfasst, die auch für die Analyse geeignet ist. Ist das nicht der Fall, ist eine Transformation erforderlich. Manche Datenbanken bauen auch auf anderen auf. So können beispielsweise Key Value Stores fast jeder Art von Datenbank zugrunde liegen.

Welche Anforderungen stellen Sie an die Latenzzeit?

Die Latenzzeit bezieht sich sowohl auf die Antwortzeit der Datenbank als auch auf die End-to-End-Antwortzeit der Anwendung. Im Idealfall hat jede Benutzeraktion eine Antwortzeit von weniger als einer Sekunde. Das bedeutet oft, dass die Datenbank bei jeder einfachen Transaktion in weniger als 100 Millisekunden reagieren muss.

Die Ausführung der Datenbank in der Cloud erschwert die Messung der Latenzzeit. Hier spielen mehrere Faktoren eine Rolle. Die einfachste Überlegung ist, dass die Latenzzeit zwischen dem Client und der Datenbank zu der Latenzzeit hinzukommt, die bereits für die Datenbankabfrage entsteht. Eine kompliziertere Überlegung: Die Übertragung von Transaktionen in einer verteilten Datenbank kann bedeuten, auf Schreibvorgänge in geografisch verteilten Regionen zu warten - insbesondere, wenn die Datenbank eine starke Konsistenz aufrechterhält.

Brauchen Sie eine geclusterte Datenbank?

Geclusterte Datenbanken können im Vergleich zu Single-Node-Datenbanken Vorteile bieten, die allerdings mit höheren Kosten und höherer Komplexität verbunden sind. Cluster versprechen beispielsweise höhere Verfügbarkeit, höheren Durchsatz und in einigen Fällen auch eine geringere Latenz.

Cluster, bei denen jeder Knoten eine Kopie der gesamten Datenbank beinhaltet, erreichen eine erhebliche Redundanz und damit eine höhere Verfügbarkeit. Je nach Richtlinie ist für einen Lesevorgang nur ein Knoten erforderlich - oder aber ein Quorum der Knoten im Cluster muss sich auf den zurückzugebenden Wert einigen.

Durch die Verwendung eines Clusters mit mehreren Knoten steht der Datenbank mehr CPU-Leistung zur Verfügung, was die Gesamtverfügbarkeit erhöht und die Transaktionsrate steigern kann. Bei einer Lesestrategie, die es dem nächstgelegenen Knoten erlaubt, einen Wert zurückzugeben, sinkt die Leselatenz normalerweise. Andererseits kann eine Schreib- oder Transaktionsrichtlinie, bei der auf die Übermittlung durch alle Knoten gewartet werden muss, manchmal die Schreiblatenz erhöhen.

Die Verwendung von Konsensgruppen hilft, die Latenz zu verringern. Wenn Sie einen Cluster mit drei Knoten haben und ein Knoten ausgelastet ist, können die beiden anderen Knoten eine Konsenstransaktion genehmigen und den dritten Knoten aktualisieren, sobald er verfügbar ist. Sharding ist eine Möglichkeit, mehr Daten zu verarbeiten, indem die Datenbank aufgeteilt wird. Während das manuelle Sharding eine zeitraubende Angelegenheit sein kann, sind viele Datenbanken in der Lage, diesen Vorgang automatisch durchzuführen.

Brauchen Sie eine verteilte Datenbank?

Clustering ist nicht der einzige Weg, um eine Datenbank zu erweitern, aber ein erster Schritt. Der nächste Schritt ist eine verteilte Datenbank, was normalerweise bedeutet, dass es Cluster in mehreren Regionen gibt. Einige Datenbanken ermöglichen verteilte Read-Replicas und eine Master-Read-Write-Instanz, andere erlauben verteilte Lese- und Schreibinstanzen oder -cluster und verfügen über Synchronisationsmechanismen.

Verteilte Datenbanken können häufig niedrigere Latenzzeiten und einen höheren Durchsatz für entfernte Benutzer bieten. Für Benutzer in Tokio kann die Latenzzeit zu einem Server in Barcelona 227 Millisekunden betragen. Gäbe es jedoch eine Datenbankkopie in Japan, könnte die durchschnittliche Lese-Latenzzeit nur 10 Millisekunden betragen. Wie sich das auf Schreibvorgänge und Transaktionen auswirkt, hängt von den Konsistenzanforderungen der Datenbank und der Konfiguration der Remote-Cluster ab.

Frühe verteilte Datenbanken waren NoSQL-Datenbanken mit eventueller Konsistenz. Eventuelle Konsistenz bedeutet, dass Lesevorgänge nach Schreibvorgängen an einem entfernten Standort nicht zwingend die aktuellen Informationen zurückgeben, sondern im Laufe der Zeit aktualisiert werden. Durch die eventuelle Konsistenz werden die Anforderungen an den Abschluss von Schreibvorgängen und Transaktionen gelockert, was zu einer geringeren Latenz führt.

In letzter Zeit haben einige verteilte Datenbanken eine starke Konsistenz implementiert, die durch Data Fabrics, Konsensgruppen und Zeitsynchronisation unterstützt wird. Beispiele hierfür sind Google Cloud Spanner und CockroachDB.

Wie hoch ist Ihr Datenbank-Budget?

Die meisten Datenbanken stehen zwar als kostenlose "Community"- oder "Entwicklungs-/Test"-Versionen zur Verfügung, doch fehlt es diesen oft an Support - von Online-Communities einmal abgesehen. Möglicherweise fehlen auch einige Leistungsoptimierungen, die in den kommerziellen Builds angeboten werden. Wenn Ihr Unternehmen auf die Datenbank angewiesen ist, sollten Sie in eine Lizenz und Support investieren.

Wenn Sie eine Datenbank in der Cloud betreiben, müssen Sie zumindest für Ihre Cloud-Ressourcen bezahlen. Für eine kommerzielle Datenbank benötigen Sie außerdem eine Datenbanklizenz, die entweder eine langfristige oder eine Pay-as-you-go-Lizenz sein kann, die über den Cloud-Anbieter erworben wird.

Cloud-Datenbanken - Anbieter

Wir haben zwölf Anbieter von Cloud-Datenbanken und -Services für Sie ausgewählt. Eine Vielzahl weiterer Lösungen finden Sie im Ranking von DB-Engines.com.

Amazon Web Services bietet mindestens 15 Datenbanken in seiner Cloud an. Allerdings handelt es sich in einigen Fällen um Data Warehouses, während einige andere veraltet sind.

• Aurora ist der hochleistungsfähige, hochverfügbare relationale Datenbankdienst von AWS, der sowohl MySQL als auch PostgreSQL unterstützt;

• RDS ist der relationale Datenbankdienst mit Standardleistung, der fünf Engines unterstützt: MariaDB, MySQL, Oracle Database, PostgreSQL und Microsoft SQL Server;

• DynamoDB ist der Key-Value-Datenbankdienst für hohen Datenverkehr;

• ElastiCache ist ein In-Memory-Dienst, der mit Memcached und Redis kompatibel ist;

• DocumentDB ist ein Dokumentendatenbankdienst, der mit MongoDB kompatibel ist;

• Keyspaces ist ein spaltenübergreifender Datenbankdienst, der mit Cassandra kompatibel ist;

• Neptune ist ein Graphdatenbankdienst, der sowohl Property-Graph- als auch RDF-Modelle unterstützt;

• Timestream ist ein Zeitreihendatenbankdienst;

• QLDB ist ein Ledger-Datenbankdienst;

Cockroach DB ist eine verteilte, horizontal skalierbare, dynamisch gesplittete, relationale Multi-Modell-Datenbank, die PostgreSQL auf einem Key-Value-Store implementiert. Sie zeichnet sich durch hohe Konsistenz und Langlebigkeit aus. CockroachDB wurde Ende 2020 um die Speicherung und Indizierung räumlicher Daten erweitert.

• CockroachDB Core ist kostenlos und quelloffen;

• CockroachDB Enterprise ist eine kommerzielle Version mit zusätzlichen Funktionen;

• CockroachCloud ist eine herstellerverwaltete Multi-Cloud-Datenbank als Service, die auf CockroachDB Enterprise und Kubernetes basiert;

• CockroachCloud Free ist die kostenlose Version von CockroachCloud mit eingeschränkter Funktionalität und einem Limit von 1 vCPU und 5 GB Speicherplatz pro kostenlosem Cluster;

Couchbase Server ist eine speicherorientierte, verteilte, flexible JSON-Dokumentendatenbank, die innerhalb eines lokalen Clusters sehr konsistent ist.

• Couchbase Lite ist eine mobile Version, die lokal läuft und sich mit dem Server synchronisieren kann, wenn eine Verbindung besteht;

• Couchbase Cloud ist eine vollständig verwaltete NoSQL-Datenbank als Service für unternehmenskritische Anwendungen, die die Bereitstellung und Verwaltung von Couchbase Server in Ihrer Cloud-Umgebung auf AWS oder Microsoft Azure automatisiert;

Datastax Enterprise ist eine erweiterte, Cloud-native Version der Open-Source-Datenbank Apache Cassandra mit vielen Spalten. DataStax Astra ist eine Cloud-native, serverlose, skalierbare, multiregionale DBaaS, die auf Apache Cassandra/DataStax Enterprise aufbaut. Durch die speichergebundene Indizierung verfügt Astra über Abfragemöglichkeiten auf nicht primären Schlüsseln, die bisher in keiner anderen Version von Cassandra verfügbar sind.

Google Cloud hostet mehr als ein Dutzend Arten von Datenbanken. Zu den relationalen Datenbanken gehören:

• Bare Metal Solution für Oracle Database,

• Cloud SQL für MySQL,

• PostgreSQL

• Microsoft SQL Server

• sowie Google Cloud Spanner, eine Cloud-native Datenbank mit unbegrenzter Skalierbarkeit, Konsistenz und 99,999 % Verfügbarkeit;

• Google Cloud Bigtable ist ein spaltenreicher Speicher ähnlich wie Cassandra oder HBase;

• Firestore und Firebase Realtime Database sind Dokumentendatenbanken;

• Memorystore unterstützt Redis- und Memcached-APIs;

• die Google Cloud Partner Services unterstützen verwaltete Angebote von MongoDB, DataStax, Redis Labs und Neo4j;

IBM bietet etwa zehn Arten von Datenbanken in seiner Cloud an. Zu den relationalen Datenbankdiensten gehören:

• PostgreSQL,

• EnterpriseDB (eine kommerzielle Erweiterung von PostgreSQL) und

• IBM Db2;

Zu den NoSQL-Datenbankdiensten gehören:

• IBM Cloudant (eine Dokumentendatenbank),

• MongoDB (ebenfalls eine Dokumentendatenbank),

• DataStax (eine kommerzielle Erweiterung von Cassandra mit breiten Spalten) und

• Redis (ein In-Memory-Datenstrukturspeicher, der als Datenbank, Cache und Message Broker verwendet wird);

IBM hostet sowohl PostgreSQL als auch MongoDB in Hyper-Protect-Umgebungen, die Ende-zu-Ende verschlüsselt sind.

Microsoft Azure unterstützt acht transaktionale Cloud-Datenbanken.

• Azure SQL ist die Cloud-native Version von SQL Server, einer relationalen Multi-Modell-Datenbank;

• Azure SQL-Instanzen sind ähnlich, bieten aber maximale Kompatibilität mit der neuesten SQL Server-Engine - sie können SQL Server auch in virtuellen Maschinen ausführen;

• Azure Database unterstützt MariaDB, MySQL und PostgreSQL;

• Cosmos DB ist ein hochverfügbarer Multi-Modell- und Multi-Region-Datenbankdienst, der Dokument-, Wide-Column-, Key-Value- und Graph-Modelle bietet, allerdings nur ein Modell pro Instanz;

• Azure Cache ist mit Redis kompatibel;

• Azure Managed Instance for Cassandra ist eine verwaltete Wide-Column-Datenbank, die mit On-Prem-Cassandra-Clustern synchronisiert werden kann;

MongoDB Atlas ist ein Multi-Cloud-Datenbankdienst für Dokumente, der auf AWS, Google Cloud und Microsoft Azure verfügbar ist. MongoDB selbst ist als verwalteter Dienst oder in virtuellen Maschinen bei fast allen Cloud-Anbietern verfügbar.

Von MySQL abgeleitet sind die Datenbanken MariaDB, Vitess, PlanetScale und SkySQL, die als Cloud-Dienst verfügbar sind. MySQL ist eine quelloffene relationale Datenbank mit mehreren Modellen, die als verwalteter Dienst in AWS, Google Cloud, Microsoft Azure und Oracle Cloud sowie in virtuellen Maschinen bei fast allen Cloud-Anbietern verfügbar ist.

• MariaDB ist eine Abspaltung von MySQL;

• Vitess ist ein Datenbank-Clustering-System für die horizontale Skalierung von MySQL mit automatischem Sharding;

• PlanetScale ist eine MySQL-kompatible, serverlose Datenbankplattform auf der Grundlage von Vitess;

• SkySQL ist ein MariaDB-Dienst, der in AWS und Google Cloud verfügbar ist;

Neo4j ist eine ACID-konforme Property-Graph-Datenbank mit vielen Clustering-Funktionen. Neo4j Aura ist eine schnelle, zuverlässige, skalierbare und vollständig automatisierte Graphdatenbank, die als Cloud-Service bereitgestellt wird. Alle Versionen von Aura sind nur in der Google Cloud verfügbar, mit Ausnahme der Enterprise-Stufe, die auch auf AWS verfügbar ist.

Oracle Database war die erste kommerzielle relationale Datenbank und ist immer noch eine führende relationale Multi-Modell-Datenbank. Sie ist in der Oracle Cloud als Service in verschiedenen Formen und Größen verfügbar. MySQL ist ebenfalls in der Oracle Cloud als Dienst verfügbar. Oracle Database ist auch für den Einsatz vor Ort und in den AWS- und Google-Clouds verfügbar.

Redis ist ein NoSQL-Speicher für In-Memory-Datenstrukturen, der auf der Festplatte gespeichert werden kann. Er kann als Datenbank, Cache und Message Broker fungieren. Es bietet hohe Verfügbarkeit über Redis Sentinel und automatische Partitionierung mit Redis Cluster.

• Redis Enterprise bietet zusätzliche Funktionen für mehr Geschwindigkeit, Zuverlässigkeit und Flexibilität und ist als Cloud-Datenbank-as-a-Service verfügbar;

• Redis on Flash ist eine Funktion von Redis Enterprise, mit der die Hardwarekostendrastisch gesenkt werden können;

Redis Enterprise Cloud-Instanzen sind auf AWS, Google Cloud und Microsoft Azure verfügbar. Sie können Ihre eigene Region (oder Regionen) wählen und Redis darüber hinaus auch in Cloud-VMs, Kubernetes oder Containern ausführen.

Cloud-DBs - Vor- und Nachbereitung

Unabhängig davon, welche Datenbank(en) Sie für Ihre Anwendung wählen, sollten Sie einen Proof of Concept durchführen, bevor Sie sich festlegen. Außerdem empfiehlt sich ein Lasttest, bevor Sie mit dem System produktiv gehen. Viele Cloud-Datenbanken können je nach Bedarf skaliert werden, aber nicht alle können dies tun, ohne Daten auf eine neue Instanz zu übertragen und die alte Instanz herunterzufahren.

Sobald Ihre Datenbank in Produktion ist, sollten Sie eine kontinuierliche Überwachung mit Warnmeldungen bei Abweichungen einrichten und für Notfälle gerüstet sein. Beachten Sie, dass bei einigen Datenbanken eine Anpassung und Änderung der Indizes erforderlich ist, wenn sich die Auslastung ändert; bei anderen Datenbanken erfolgt die Anpassung automatisch. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.