Amazon RDS versus Redshift: wann verwendet man was?

Was sind die wichtigsten Gemeinsamkeiten?

Sowohl RDS als auch Redshift verwenden SQL für den Zugriff auf Daten. Beide verwalten die Computing- und Storage-Infrastruktur, um Skalierbarkeit, Verfügbarkeit und Sicherheitsfunktionen zu optimieren. Für die Software werden die Daten in logischen Datenbanken und Schemata gruppiert, in Tabellen gespeichert und in Zeilen und Spalten organisiert. Amazon Redshift basiert auf PostgreSQL, einer weit verbreiteten Datenbank-Engine. Beide bieten Anwendern eine praktische Möglichkeit, Daten zu speichern, darauf zuzugreifen und sie den Endbenutzern zur Verfügung zu stellen.

Was sind die Hauptunterschiede?

RDS und Redshift unterscheiden sich in einigen wichtigen Bereichen. Dazu gehören beispielsweise das zugrunde liegende Design, der Bereitstellungs- und Skalierungsansatz und der Datenzugriff. Auch die Kosten sind unterschiedlich.

Aufbau. Der wichtigste Unterschied zwischen RDS und Redshift ist das Design der Datenverarbeitung. Da RDS ein relationaler Datenbankdienst ist, verfügt RDS über ein OLTP-Design (Online Transaction Processing). OLTP-Programme folgen einem transaktionalen Prozess. Das bedeutet, dass die Daten vor gleichzeitigen Änderungen und vor Beschädigungen durch fehlgeschlagene Prozesse geschützt sind. Redshift auf der anderen Seite hat sich einem OLAP-Ansatz (Online Analytical Processing) verschrieben. OLAP bereinigt und organisiert Daten aus Data Warehouses in strukturierten Data Cubes, um sie für Abfragen vorzubereiten. Dieser Unterschied bedeutet, dass sie zwei verschiedene Probleme lösen.

RDS ist für Online-Transaktionen in Echtzeit gedacht, die eine sofortige Antwort erfordern. Redshift eignet sich für Aufgaben mit längeren und umfangreicheren Datenanalysen, die asynchron ausgeführt werden können.

Bereitstellung und Skalierbarkeit. Die Bereitstellung einer RDS-Datenbank besteht aus mehreren Schritten:

• Starten einer Datenbankinstanz
• Auswahl der Instanzfamilie, zum Beispiel T3, M5 oder R5
• Auswahl der Größe, zum Beispiel large, xlarge, 4xlarge oder andere
• Auswahl des Speichertyps, entweder Allzweck-SSD oder bereitgestellte IOPS
• Einstellung der Speicherkapazität

Im Falle von RDS Aurora – einer MySQL- und PostgreSQL-kompatiblen Datenbank innerhalb von AWS RDS – muss der Kunde eine Datenbank innerhalb eines RDS-Clusters starten. Ein Cluster besteht aus einem einzelnen primären Knoten und einer optionalen Anzahl von Lesereplikaten (Read Replicas) sowie Multi-AZ oder regionalen Backup-Alternativen. RDS speichert alle Quelldaten in einem einzigen Knoten. Die einzige Möglichkeit, Storage zu skalieren, besteht darin, die Festplattenkapazität in der RDS-Instanz zu erhöhen. Durch das Hinzufügen weiterer Lesereplikate kann der primäre Knoten entlastet werden. Allerdings ist der primäre Knoten immer noch der einzige Punkt, an dem die Quelldaten gespeichert und verwaltet werden.

Für die Bereitstellung eines Redshift-Clusters wählt der Kunde:

• Knotentyp, zum Beispiel RA3, DS2 oder DC2
• Knotengröße, zum Beispiel large, xlarge, 8xlarge oder eine andere Größe
• Anzahl der Knoten

Im Falle von RA3-Knoten können Redshift-Benutzer die Speichermenge pro Knoten angeben. Ansonsten ist sie entsprechend der Knotengröße vordefiniert. Anwender können die Speicherkapazität des Clusters durch Hinzufügen von Knoten oder Aktualisieren der Speichereinstellungen erhöhen. Die Daten werden gleichmäßig auf die Knoten verteilt, was den Anwendern eine gute Skalierbarkeit erlaubt. Rechenleistung und Storage werden auf mehrere Knoten verteilt. Daher ist die Skalierbarkeit für einen Redshift-Cluster im Vergleich zu einer RDS-Bereitstellung wesentlich höher.

Datenzugriff. RDS-Datenbanken sind nicht für den Zugriff auf Daten ausgelegt, die außerhalb ihres lokalen Speichersystems und ihres vordefinierten Formats gespeichert sind. Redshift hingegen kann auf Daten zugreifen, die entweder lokal im Cluster oder auf externen Datenquellen gespeichert sind.

Für extern gespeicherte Daten unterstützt Redshift mehrere Formate. Dazu gehören beispielsweise ORC, Parquet, JSON und CSV. Außerdem ist Redshift für die Speicherung und den Zugriff auf viel größere Datensätze als RDS konzipiert und optimiert. Dies können bis zu 128 TB pro Knoten sein, so dass insgesamt in einem Cluster Petabytes an Daten gemanagt werden können. Vergleichen Sie dies mit RDS: Dieses erreicht bei den meisten Datenbank-Engines nur 100 Gibibytes bis 64 TB. Redshift hingegen wird nur durch die Beschränkungen der externen Datenspeicherung begrenzt. Im Falle des Amazon S3 Cloud Storage gibt es praktisch keine Schranken.

Kosten. In Bezug auf die Kosten ist ein Vergleich der beiden Lösungen nicht so einfach.

Bei RDS richten sich die Preise nach der Datenbank-Engine, der Instanzgröße und dem Speicherplatz. Die teuerste RDS-Instanz (Microsoft SQL Server Enterprise db.x1.32xlarge) kann bis zu 45.000 US-Dollar pro Monat kosten. Es gibt jedoch auch produktionsreife Optionen, die Kunden für 1.000 Dollar oder weniger nutzen können, wie zum Beispiel RDS MySQL m5.4xlarge.

Der teuerste Redshift-Knoten (ra3.16xlarge) kostet etwa 9.400 US-Dollar pro Monat. Dies würde bedeuten, dass ein Cluster mit mehreren Knoten potenziell mit 50.000 bis 100.000 US-Dollar pro Monat zu Buche schlägt. Strategien für das Kostenmanagement, wie zum Beispiel die Optimierung der richtigen Größe von Knoten und Clustern, können die Kosten für beide Produkte senken.

Die Kosten für einen Redshift-Cluster sind zwar größer als die entsprechenden Kosten für RDS. Redshift ermöglicht aber eine wesentlich höhere Rechen- und Speicherkapazität als eine RDS-Bereitstellung.

Nutzung in der realen Welt

In der Praxis eignet sich eine von RDS verwaltete relationale Datenbank für Anwendungen wie Online-Anfragen. Denken Sie an Anfragen, die von einer Web- oder Mobilanwendung kommen, wie zum Beispiel eine Benutzeranmeldung, die Suche in einem Produktkatalog oder die Ausgabe von Benutzerdetails.

Ein Redshift-Cluster hingegen ist prädestiniert für die Erstellung von Berichten, die auf großen Datenmengen basieren. Dies können zum Beispiel Reports über den Website-Verkehr sein, Benutzeraktivitäten, Protokollanalysen, Markt- oder Geschäftsberichte, Abrechnungsanalysen für große Plattformen und Analysen öffentlicher Datensätze. Der Redshift-Benutzer kann die Berichterstellung automatisch auslösen. Er sollte aber damit rechnen, dass die Verarbeitung einige Zeit in Anspruch nimmt. Nach Fertigstellung des Berichts kann der Output von Redshift in ein Format exportiert werden, auf das andere Anwendungskomponenten zugreifen können, beispielsweise Visualisierungs-Tools für Business Intelligence, interne Berichte und Online-Anwendungen.

Die richtige Wahl treffen

Auch wenn Redshift auf PostgreSQL basiert, gibt es viele Funktionen und Designs dieser Engine, die von Redshift nicht unterstützt werden. In der AWS-Dokumentation werden diese im Detail beschrieben.

Redshift unterstützt sowohl einen Data-Warehouse- als auch einen Data-Lake-Ansatz. Weil Redshift die lokale Speicherung in den Clusterknoten ermöglicht, stimmt dieses Modell mit der Data-Warehouse-Philosophie gut überein. Nach dieser Philosophie werden die Daten intern nach einer vordefinierten Struktur verarbeitet und gespeichert.

Redshift ermöglicht jedoch auch ein Data-Lake-Modell. In diesem Modell greift es auf extern gespeicherte Daten zu, zum Beispiel in S3- oder RDS-Datenbanken. Redshift interagiert mit einem Datenkatalog, der entweder auf dem interaktiven Abfrageservice Amazon Athena basiert, dem serverlosen Service für Datenintegration AWS Glue oder dem Data Warehouse und Analysepaket EMR Hive. Mit allen lässt sich auf die externen Datenquellen zugreifen. Die Redshift-Funktion für föderierte Abfragen ermöglicht die Verbindung mit Datenbanken, die von RDS verwaltet werden und die Aurora MySQL-, MySQL- und PostgreSQL-Engines nutzen.

Sowohl RDS als auch Redshift helfen bei der Lösung komplexer Probleme, insbesondere wenn es um die Bereitstellung von Infrastruktur und die Verwaltung von Datenspeichern geht. Bei beiden Systemen handelt sich um unterschiedliche Dienste, die unterschiedliche Probleme lösen. Wenn sie für den richtigen Anwendungsfall eingesetzt werden, sind beide Plattformen leistungsstark und sollten als Teil eines Tool-Sets für die Bereitstellung moderner Applikationen in der Cloud betrachtet werden.