Die Vielfalt verfügbarer Speichertechnologien hat insbesondere in der Cloud rasant zugenommen. 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.
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.
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–Datenbankensind 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 Datenbankenkö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).
