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

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.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK 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 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.

Data Warehousing mit RedShift

Zwar kann man auch Data Warehouse-Lösungen auf AWS-Instanzen betreiben, interessanter ist hier aber allemal der von AWS als verwaltetes Data Warehouse bereitgestellte Dienst AWS RedShift. Der Einsatz von RedShift empfiehlt sich insbesondere dann, wenn ScaleOut zwingend benötigt wird.

Obwohl es sich auch bei Data Warehouses prinzipiell um relationale Datenbanken handelt, unterstützt RedShift einen horizontalen ScaleOut auf bis zu 128 Knoten vom Typ ds2.8xlarge mit 244 Gigabyte RAM und einer maximalen Cluster-Kapazität von 2 Petabyte. Im Detail hängt die maximale Anzahl von RedShift-Knoten vom Knotentyp ab.

Prinzipiell unterstützt RedShift bis zu 100 Datenbanken pro Konto, 100 Tabellen pro Datenbank und 20.000 Partitionen pro Tabelle. Im Gegensatz zu herkömmlichen SQL-Datenbanken sind die Daten hier spaltenweise gespeichert. Dies ist allein schon deshalb sinnvoll, weil man beim Reporting mit überwiegend lesenden Zugriffen rechnet.

Darüber hinaus lassen sich die Daten sehr effizient aggregieren, da die spaltenweise Speicherung z. B. für Summenbildung und Aggregationen optimiert ist, und extrem hoch komprimieren. Red Shift kann die Daten optional verschlüsseln und ist als relationale Datenbank kompatibel mit vielen bekannten BI-Tools, weil man über gängige ODBC-/ JDBC-Treiber (konkret wird der Postgres-Treiber verwendet) auf die Daten zugreift.

Elastic Map Reduce

Aufgrund der schnellen und einfachen Verfügbarkeit von Map Reduce auf AWS – z. B. in Form des Services Elastic Map Reduce (EMR) – und weil Hadoop z. B. mittels HiveQL auch Quasi-SQL-Abfragen unterstützt, nutzt eine wachsende Anzahl von AWS-Anwendern auch Hadoop als Data-Warehouse-Lösung bzw. für Analytics-Aufgaben. Dies ist zwar durchaus möglich, allerdings wurde Hadoop keineswegs zu diesem Zweck entwickelt oder in irgendeiner Weise optimiert.

Hadoop ist eine verteilte Rechen-Engine (Compute) und wird primär eingesetzt, um komplexe Berechnungen auf großen Datenmengen auszuführen, bzw. für komplexe ETL-Jobs. Allerdings lässt sich Hadoop durchaus hervorragend als Vorverarbeitungsstufe für RedShift verwenden.

Ein klassischer Use Case hierfür wäre das Bereinigen bzw. Aufbereiten von Webserver-Logs für die nachfolgende Analyse in RedShift. Diese Art von vorheriger Bereinigung mittels Map Reduce ist sinnvoll, weil in Webserver-Logs im Normalfall keine einheitlichen Daten stehen, was sie prinzipiell erstmal ungeeignet für Data Warehouse macht. Hier mischen sich z. B. verschiedene Arten von Fehlermeldungen mit unterschiedlichsten Typen von Log-Einträgen, was sich mit EMR gut bereinigen, bzw. normieren lässt.

Ein EMR-Cluster ist in der AWS Management Console schnell erstellt. Nach einem Klick auf „Create Cluster“ legt man meine Cluster-Namen fest, bestimmt ein S3-Bucket für das Logging und wählt dann bei „Software configuration“ die gewünschten im EMR-Cluster bereitzustellenden „Applications“. Vier vorkonfigurierte Sets sehen hier bereit, man kann aber mit einem Klick auf „Go to advanced configuration“ auch eine gezielte Auswahl treffen. Bei „Hardware configuration“ legt man die Cluster-Größe fest. Der Wert bei „Number of instances“ versteht sich immer als „1 master + n core“-Nodes.

Auf diese Weise sind zusammen mit EMR und RedShift verschiedene Datenverarbeitungs-Workflows vorstellbar. So könnte man im Webserver-Log-Beispiel EMR gut für die Vorverarbeitung nutzen, indem man die Massendaten als Ergebnis des EMR-Laufs für das spätere Reporting bzw. für die Nutzung von BI-Tools an RedShift weiterleitet. Dabei ist es aber durchaus möglich, parallel direkt auf dem EMR-Cluster Analysen abzugreifen, quasi während der Vorverarbeitung.

NoSQL

Der Hauptgrund für den Einsatz von NoSQL-Datenbanken ist massives ScaleOut. Da NoSQL-Datenbanken auf einem verteilten, hoch skalierbaren Cluster laufen, sind sie immer erste Wahl, wenn man mehr als einen Knoten braucht (Standard bei relationalen Datenbanken). Dabei bleiben Durchsatz und IOPS gleichbleibend hoch, wobei die Zugriffszeit auf bei 150.000 IOPS und wachsender Clustergröße wegen der verteilten Speicherung sehr niedrig bleibt.

Mehr aus Entwicklersicht punktet NoSQL-Datenbanken mit Ihrem flexiblen Schema. Das Schema darf allerdings nur relativ einfach sein, kann dann aber auch im laufenden Betrieb geändert werden, d. h. das Datenmodell sieht flexible Attribute vor. Dafür ist der Funktionsumfang stark eingeschränkt. Im der Regel handelt es sich um mehr oder weniger einfache Key-Value-Stores.

Während man sich bei einer relationalen Datenbank sehr stark auf ein bestimmtes Schema festlegt (Tabellen, Spalten), hat man in NoSQL sehr viele unterschiedliche Entitäten und vor allem sehr unterschiedliche Eigenschaften für jede einzelne Entität. Daher eignen sich NoSQL-Datenbanken immer gut, wenn sich das Schema häufig ändert. Der dritte Grund für den Einsatz von NoSQL ist die extrem niedrige Latenz. Wenn man niedrige Latenz im 1stelligen ms-Bereich braucht, geht kein Weg an NoSQL vorbei, ein Wert der mit relationalen Datenbanken zumindest bei größeren Transaktionsvolumen nicht zu machen ist.

Der größte Nachteil von NoSQL ist, dass sie die ACID-Prinzipien nicht erfüllen und daher Transaktionen nicht möglich sind. Von Anfang an kennen NoSQL-Datenbanken allerdings mit BASE (Basicly Available, Soft State, Eventually Consistency) ein ähnliches Konzept.

• BA bedeutet, dass die Verfügbarkeit der Datenbank über die Konsistenz gewertet wird, d. h. Verfügbarkeit bleibt auch bei Ausfall von Einzelkomponenten gewahrt bleiben.

• Soft State impliziert, dass NoSQL keinen harten Transaktionszustand kennt.

• Eventually Consitant heißt, dass man einmal geschriebene Daten auch irgendwann lesen kann, aber nicht notwendigerweise sofort. Moderne NoSQL-Datenbanken bieten heute aber auch vollkommen transaktionale Schreiboperationen, also volle Konsistenz, allerdings meist aber nur für einzelne Objekte.

Auch NoSQL-Datenbanken wie Cassandra, CouchDB, MongoDB etc. lassen sich unter AWS DIY auf Basis von EC2-Instanzen betreiben. Einfacher ist wie immer das Verwenden einer von AWS verwalteten NoSQL-Datenbank wie „DynamoDB“ mit einem provisionierten Durchsatz von bis zu 150.000 Schreiboperationen pro Sekunde bei niedrigster Latenz im einstelligen Millisekunden-Bereich, was dadurch gewährleistet wird, dass die Datenbank bei Bedarf in Hintergrund dynamisch skaliert und die Daten selbst immer auf SSDs liegen.

(ID:45385338)