Tools und Workflows zur Datenspeicherung in der Cloud, Teil 1 Datenbanken und Data Warehouses unter AWS

Autor / Redakteur: Dipl. -Ing. Thomas Drilling / Stephan Augsten

Die Vielfalt verfügbarer Speichertechnologien hat insbesondere in der Cloud rasant zuggenommen. Der Beitrag spannt am Beispiel AWS einen Bogen über das Portfolio von relationalen Datenbanken über Data Warehouses, NoSQL, S3-Objectstore bis hin zu Big Data.

Beispiel für ein kombiniertes EMR- und RedShift-Einsatzszenario.
Beispiel für ein kombiniertes EMR- und RedShift-Einsatzszenario.
(Bild: Drilling / AWS Germany GmbH)

Cloud-Einsteiger finden sich in der Regel mit einer Vielzahl verfügbarer Speichertechnologie für Ihre Kunden- und Unternehmensdaten konfrontiert. Für viele findet sich eine Entsprechung in der On-Premises-Welt, Einige sind aber auch spezifisch für die Cloud.

Auch wenn sich bestehende Speicherkonzepte wie z. B. Datenbanken oft eins zu eins in die Cloud übernehmen lassen, bieten Cloud-spezifische Lösungen – und sei es auch nur die verwaltete Form einer relationalen Datenbank – häufig Vorteile. Big Data-Lösungen oder Data-Lake-Konzepte hingegen lassen sich ohne die Cloud oft gar nicht oder nicht zu realistischen Kosten betreiben.

Bevor es AWS-spezifisch wird, eine kurze Übersicht der wichtigsten Speicherkonzepte. Im Übrigen geht es auch in der Cloud nicht darum, etwa Relationale Datenbanken per se durch NoSQL oder Data Warehouses und ERP-Systeme durch Data Lakes, sowie klassische BI-Lösungen durch Quicksight zu ersetzen.

Alle besitzen nach wie vor ihre Daseinsberechtigung; die Cloud macht nur den Betrieb einfacher und wirtschaftlicher, erlaubt bei Bedarf einfache Transformationen zwischen den Systemen – etwa durch die Bereitstellung verwalteter ETL-Lösungen –, erschließt aber z. B. im Umfeld von Big Data auch gänzlich neue Use Cases.

Relationale Datenbanken

Das Konzept der Relationen Datenbank tauchte erstmals um 1970 herum in der Informationstechnik auf. Kommerzielle Produkte gibt seit Mitte der Siebziger Jahre, entsprechend ausgereift sind die heute verfügbaren Lösungen.Sie haben sich für viele Anwendungsfälle bewährt, woran auch NoSQL und die Cloud nichts ändert. SQL-Datenbanken sind in folgenden Szenarien unverzichtbar:

  • 1. Komplexes, aber in der Regel unveränderliches Schema mit vielen Entitäten und Beziehungen; oder allgemein, wenn ein großer Funktionsumfang gefordert ist.
  • 2. Support für Transaktionen und OLTP, insbesondere wenn es um die Gewährleistung und Einhaltung der ACID-Regeln geht, was für alle modernen SQL-Datenbanken gilt. ACID steht seit 1983 im Zusammenhang mit Transaktionen und insbesondere Online Transaktionen (OLTP) für Atomarität (Abgeschlossenheit), Consistency (Konsistenz), Isolation (Abgrenzung) und Durability (Dauerhaftigkeit). ACID ist überall dort eine zwingend zu erfüllende Forderung, wenn es um das Thema Geld geht. Das klassische Beispiel ist eine Überweisung einer bestimmten Geldsumme von einem Konto A auf ein Konto B.

Relationale Datenbanken haben aber auch Nachteile. So sind vor allem der Performance (IOPS, Durchsatz) natürliche Grenzen gesetzt, da sie nicht horizontal skalieren, sieht man mal von Konzepten wie Sharding ab.

Die meisten heutigen Engines unterstützen aber zumindest eine Art von synchronen Spiegel zur Erhöhung Verfügbarkeit, sowie Read Replicas. Unter AWS verwaltete relationale Datenbanken können je nach Instanztyp (vertikal skalieren geht immer) bis zu 30.000 IOPS (Ein-/Ausgabeoperationen pro Sekunde) erzielen. Sind die Anforderungen und Transaktionsvolumina deutlich höher, muss man ohnehin nach einer geeigneten NoSQL-Datenbank Ausschau halten.

Unter AWS finden sich verschiedene Datenbank-Engines.
Unter AWS finden sich verschiedene Datenbank-Engines.
(Bild: Drilling / AWS Germany GmbH)

Unter AWS lassen sich nahezu beliebige SQL-Datenbanken (MariaDB/MySQL, PostgresQL, Oracle, MS SQL Server u.v.m.) auf Basis von EC2-Instanzen betreiben, allerdings hat man dann den gleichen administrativen Aufwand hinsichtlich Patching, Verfügbarkeit, Absicherung oder Backups, wie bei einer On-Premises betriebenen Datenbank.

Optional stellt AWS im Rahmen seines Dienstes RDS (Relational Database Service) eine vollständig verwaltete Version zum Betrieb der wichtigsten Engines für Relationale Datenbanken auf von AWS verwalteten EC2-Instanzen bereit. RDS unterstützt MariaDB, MySQL, Amazon Aurora, PostgresQL, MS SQL Server und Oracle in den unterschiedlichsten Versionen, bei Bedarf auch mit BYOL (Bring your own license).

Der Vorteil für den Nutzer: AWS kümmert sich um den zuverlässigen Betrieb der benötigen Instanzen und sorgt durch Replikationstechnologien für eine hohe Verfügbarkeit des angehängten Speichers. AWS kümmert sich dabei automatisches um OS- und DB-Patches im vom Nutzer definierten Wartungsfenster, führt auf Wunsch automatisch Backups aus und erlaubt komfortable Snapshots. Auf Wunsch gibt es per Mausklick mit dem Multi-AZ-Feature hohe Verfügbarkeit durch synchrones Spiegeln in einer zweiten Availability Zone (AZ), was z. B. auch die Downtime beim vertikalen Skalieren der primären Instanz minimiert.

Read Replicas unterstützt RDS zur Erhöhung der Performance ebenfalls per Mausklick, allerdings handelt es sich hier um ein Feature der jeweiligen DB-Engine. Außerdem ist RDS mit IAM und anderen AWS-Diensten integriert. Ein Alleinstellungsmerkmal hinsichtlich der Performance ist die Möglichkeit, den unterliegenden Instanz-Speicher auf Basis von SSD mit der Option Provisioned IOPS (PIOPS) zu buchen, wobei bis zu 30000 IOPS möglich sind.

Data Warehouse + Reporting

Der zweite große Anwendungsfall für relationale Datenbanken – neben OLTP – sind Reporting und Analytics. Während es bei OLTP primär darum geht, aus einer großen Menge Datensätze einzelne Datensätze zu lesen und zu schreiben, z. B. eine Bestellung und einem Warenwirtschaftssystem, geht es beim Reporting im Wesentlichen darum, aus großen Datenmengen große Auswertungen zu fahren.

Man greift also nicht auf einzelne Datensätze zu, sondern mittels „Aggregationen“ (Summen, Durchschnittswerte, Minima, Maxima) auf ebenfalls, diesmal (aggregierte) Datenmengen, aber nur lesend. Ideal für solche Zwecke sind Data Warehouses. Hier ist das Schema ggf. ebenfalls sehr komplex.

(ID:45385338)