AWS: Aurora als Alternative zu RDS PostgreSQL

11.11.2022

Applikationen benötigen oft eine relationale Datenbank, um ihre Daten speichern zu können. Eine viel genutzte Datenbank ist hierbei PostreSQL. Neben der klassischen Lösung, dem Betrieb der Datenbank im unternehmenseigenen Rechenzentrum, gibt es bei Anbietern wie Azure oder AWS auch eine Variante, die in der Cloud verfügbar ist.

Der AWS Service RDS (Relational Database Service) bietet die Möglichkeit, Datenbank-Engines wie Oracle, MySQL, MS SQL und PostgreSQL auf Cloud-Infrastruktur zu betreiben. Allerdings gibt es mit Aurora eine weitere Engine, die neben MySQL auch PostgreSQL Kompatibilität bietet.

 

Sollen nun Applikationen mit PostgreSQL in der Cloud betrieben werden, stellt sich oft die Frage, welche Variante ausgewählt werden soll – RDS PostgreSQL oder Aurora für PostgreSQL. Beide Varianten versprechen volle Kompatibilität zu PostgreSQL, so dass es für die Applikation selbst keinen Unterschied macht, welche der beiden Lösungen angebunden wird. Allerdings unterscheidet sich die Architektur der beiden Varianten grundlegend, so dass sich in Projekten oft die Frage stellt, welche Lösung die geeignetere ist.

Gemeinsamkeiten von RDS PostgreSQL und Aurora PostgreSQL

Sowohl RDS PostgreSQL als auch Aurora werden innerhalb des AWS Services RDS betrieben und teilen sich die grundlegenden Möglichkeiten dieses Services. Beide Varianten sind „fully managed“ – AWS kümmert sich also um den Betrieb und die Wartung der Infrastruktur. Sie bieten die Möglichkeit von MultiAZ, also dem Betrieb in mehreren Rechenzentren in einer Region, um eine hohe Ausfallsicherheit zu gewährleisten. Darüber hinaus werden Lösungen für Failover und Recovery, Skalierung und automatisierte Backups angeboten. Beide Lösungen beherrschen den Einsatz von sogenannten Read Replicas. Hierbei wird die Datenbank parallel auf mehreren Servern betrieben und Datenänderungen von der primären Instanz in die anderen Instanzen synchronisiert. Über diesen Mechanismus ist es beispielsweise möglich, Schreiboperationen von aufwändigen Datenabfragen zu trennen.

Unterschiede zwischen PostgreSQL und Aurora PostgreSQL

PostgreSQL wurde nicht mit dem Fokus auf Cloudtechnologien entwickelt, hat sich aber über viele Jahre bewährt. Hierbei setzt PostgreSQL zur Speicherung der Daten auf sogenannten Blockstorage. Die Daten werden in einzelne Blöcke aufgeteilt, mit Adressen versehen und gespeichert. Mit diesem Prinzip arbeiten beispielsweise Festplatten sowie der AWS Elastic Block Storage (EBS), der bei RDS PostgreSQL als persistenter Speicher zum Einsatz kommt. Werden nun mehrere Replikas eingesetzt, synchronisiert die PostgreSQL die Daten über einen Streaming Mechanismus. Dies hat zur Folge, dass ein gewisser Anteil der Rechenleistung der Datenbankinstanzen für diese Synchronisierung benötigt wird. Außerdem kommt es während der Synchronisierung zu Verzögerungen, die je nach Auslastung der CPU schwanken können (dem sogenannten Replication Lag).

Aurora
Quelle: eigene Darstellung

Aurora ist eine von AWS entwickelte Datenbanklösung und setzt auf die Möglichkeiten der Cloud. Im Gegensatz zu PostgreSQL wird eine verteilte Speicherlösung eingesetzt. Nicht die Datenbank synchronisiert die Daten, sondern der Speicher selbst übernimmt diese Aufgabe. Hierbei kommt ein Verbund von SSDs zum Einsatz, die zu einem virtuellen Speicher zusammengefasst werden. Dabei ist garantiert, dass nach einem Schreibvorgang während des darauffolgenden Lesens der Daten immer das gleiche Ergebnis geliefert wird (read-after-write-consistency). Eine Synchronisierung auf Datenbankebene ist also nicht erforderlich und Datenänderungen stehen allen Instanzen gleichzeitig zur Verfügung.

Aurora
Quelle: eigene Darstellung

Die Unterschiede der beiden Speicherlösungen wirken sich auf verschiedene Aspekte des Datenbankbetriebs aus:

  • Synchronisierung: Wie bereits beschrieben werden Daten bei PostgreSQL über Streams synchronisiert, bei Aurora hingegen über den verteilten Speicher. Im Falle von Aurora hat dies keinen Einfluss auf die Leistungsfähigkeit der Datenbank und Daten sind auf allen Instanzen auf dem gleichen Stand.
  • Crash Recovery: Im Betrieb eines produktiven Systems ist es äußerst wichtig, wie schnell das System nach einem Ausfall wieder zur Verfügung steht. PostgreSQL erstellt hierzu in bestimmten Intervallen (5 Minuten als Standard) sogenannte Checkpoints. Änderungen zwischen den Checkpoints werden in sogenannte Transaction Logs gespeichert. Im Falle eines Ausfalls wird der letzte Checkpoint wiederhergestellt und die Änderungen aus dem Transaction Log erneut eingespielt. Da es sich hierbei um Input/Output intensive Operationen handelt, wird in dieser Zeit die Leistung der Datenbank reduziert.
    Bei Aurora erfolgt Crash Recovery nicht in der Datenbank selbst sondern mit Hilfe von parallelen Threads in der Speicherlösung. Hierdurch gibt es keine Auswirkungen auf die Leistungsfähigkeit der Datenbank so dass diese in der Regel schneller wieder vollumfänglich zur Verfügung steht.
  • Speichertechnologie: PostgreSQL nutzt Elastic Block Storage auf SSDs. Eine Skalierung ist automatisch bis 64 TiB möglich. Aurora nutzt ebenfalls SSDs, setzt aber auf einen verteilten Speicher. Hierbei kann bei Aurora automatisch bis 128 TiB skaliert werden.
  • Backups: Backups werden zu definierten Zeitfenstern erstellt . Wird eine Lösung mit nur einer Datenbank Instanz genutzt, wirkt sich die Erstellung des Backups auf die Leistung der Datenbank aus. Bei Aurora wird der verteilte Speicher selbst inkrementell gesichert. Die Daten werden hierbei über eine definierte Aufbewahrungszeit vorgehalten. Durch die inkrementelle Sicherung kann die Wiederherstellung der Daten auf einen bestimmten Zeitstempel erfolgen.
  • Instanzgrößen: PostgreSQL bietet eine Auswahl von General Puropse- und speicheroptimierten Instanzen. Die Zahl der unterschiedlichen Instanzgrößen ist höher als bei Aurora.
  • Kosten: Die Kosten für PostgreSQL setzen sich aus der Instanzgröße und dem EBS Volume zusammen. Auf Read Replicas entfallen zusätzliche Kosten.
    Grundlage der Kosten für Aurora sind die Instanzgröße und die aktuelle Nutzung der Datenbank. Auf Read Replicas entfallen ebenfalls zusätzliche Kosten. Die Kosten liegen für Aurora in der Regel 20 Prozent über denen von PostgreSQL bei vergleichbaren Workloads.

Neben diesen Unterschieden bietet Aurora noch weitere Features, die es in dieser Form bei PostgreSQL nicht gibt. Hierzu gehören das schnelle Klonen von Datenbanken und Aurora Serverless, also das automatische Skalieren von Datenbanken anhand des Bedarfs der Anwendung, so dass bei unvorhersehbaren oder seltenen Zugriffen Kosten eingespart werden können. Mit Aurora Global Database kann über Regionen hinweg eine verteilte Datenbank aufgespannt werden. So können je nach Ort der Anfrage Latenzen weltweit von weniger als 1 Sekunde ermöglicht werden. PostgreSQL hat hier im Rahmen der cross-Region Replikation höhere Verzögerungen.

Aurora oder PostgreSQL? Die Wahl der richtigen Engine

Aurora ist die modernere Engine und setzt konsequent auf Cloudtechnologien. In den meisten Kategorien ist Aurora der PostgreSQL Engine überlegen. Stehen die Kosten im Vordergrund oder wird eine Instanzgröße benötigt, die bei Aurora nicht angeboten wird, sollte die Wahl auf Postgres fallen. Spielen Themen wie Recovery-Zeit, inkrementelles Backup etc. keine große Rolle, ist der Einsatz von PostgreSQL eine mögliche Lösung. Werden mehr als 64TiB Speicher benötigt, muss Aurora genutzt werden.

 

Mehr über Softwareentwicklung erfahren

 

Quellen

Details zu RDS Aurora: https://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraOverview.html
Details zu RDS PostgreSQL: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html

Zurück zur Übersicht

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

*Pflichtfelder

*