Auswahl einer Datenbank für eine SaaS-Anwendung

Bei vielen mehrinstanzenfähigen SaaS-Anwendungen kann die Auswahl einer betriebsbereiten Datenbank auf die Wahl zwischen relationalen und nicht relationalen Datenbanken oder einer Kombination aus beidem reduziert werden. Berücksichtigen Sie bei Ihrer Entscheidung die folgenden allgemeinen Anforderungen und Merkmale von Anwendungsdaten:

• Datenmodell der Anwendung

• Zugriffsmuster für die Daten

• Anforderungen an die Datenbanklatenz

• Anforderungen an Datenintegrität und Transaktionsintegrität (Atomizität, Konsistenz, Isolierung und Haltbarkeit oder ACID)

• Regionsübergreifende Verfügbarkeits- und Wiederherstellungsanforderungen

In der folgenden Tabelle werden die Anforderungen und Merkmale von Anwendungsdaten aufgeführt und im Zusammenhang mit AWS Datenbankangeboten erörtert: Aurora PostgreSQL-kompatibel und Amazon RDS für PostgreSQL (relational) sowie Amazon DynamoDB (nicht relational). Sie können auf diese Matrix zurückgreifen, wenn Sie versuchen, sich zwischen relationalen und nicht-relationalen operativen Datenbankangeboten zu entscheiden.

Datenbanken	Anforderungen und Eigenschaften von SaaS-Anwendungsdaten
	Datenmodell	Zugriffsmuster	Anforderungen an die Latenz	Daten- und Transaktionsintegrität	Regionsübergreifende Verfügbarkeit und Wiederherstellung
Relational (Aurora PostgreSQL-kompatibel und Amazon RDS für PostgreSQL)	Relational oder stark normalisiert.	Muss nicht im Voraus gründlich geplant werden.	Vorzugsweise höhere Latenztoleranz; kann standardmäßig mit Aurora und durch Implementierung von Read Replicas, Caching und ähnlichen Funktionen niedrigere Latenzen erreichen.	Standardmäßig wird eine hohe Daten- und Transaktionsintegrität beibehalten.	In Amazon RDS können Sie eine Read Replica für regionsübergreifende Skalierung und Failover erstellen. Aurora automatisiert diesen Prozess größtenteils. Für mehrere AWS-Regionen Active-Active-Konfigurationen können Sie die Schreibweiterleitung in Verbindung mit den globalen Aurora-Datenbanken verwenden.
Nicht relational (Amazon DynamoDB)	Normalerweise denormalisiert. Diese Datenbanken nutzen Muster für die Modellierung von many-to-manyBeziehungen, großen Datenmengen und Zeitreihendaten.	Alle Zugriffsmuster (Abfragen) für Daten müssen gründlich verstanden werden, bevor ein Datenmodell erstellt wird.	Sehr niedrige Latenz mit Optionen wie Amazon DynamoDB Accelerator (DAX), die die Leistung noch weiter verbessern können.	Optionale Transaktionsintegrität auf Kosten der Leistung. Bedenken hinsichtlich der Datenintegrität werden auf die Anwendung verlagert.	Einfache regionsübergreifende Wiederherstellung und Active-Active-Konfiguration mit globalen Tabellen. (Die ACID-Konformität ist nur in einer einzigen Region möglich.) AWS

Einige mehrinstanzenfähige SaaS-Anwendungen haben möglicherweise einzigartige Datenmodelle oder besondere Umstände, die besser mit Datenbanken bedient werden können, die nicht in der vorherigen Tabelle enthalten sind. Beispielsweise können Zeitreihendatensätze, stark vernetzte Datensätze oder die Verwaltung eines zentralen Transaktionsbuchs die Verwendung eines anderen Datenbanktyps erforderlich machen. Die Analyse aller Möglichkeiten würde den Rahmen dieses Leitfadens sprengen. Eine umfassende Liste der AWS Datenbankangebote und wie sie verschiedene Anwendungsfälle auf hohem Niveau erfüllen können, finden Sie im Abschnitt Datenbank des Whitepapers Überblick über Amazon Web Services.

Der Rest dieses Handbuchs konzentriert sich auf AWS relationale Datenbankdienste, die PostgreSQL unterstützen: Amazon RDS und Aurora PostgreSQL-kompatibel. DynamoDB erfordert einen anderen Ansatz zur Optimierung für SaaS-Anwendungen, was den Rahmen dieses Handbuchs sprengen würde. Weitere Informationen zu DynamoDB finden Sie im AWS Blogbeitrag Partitioning Pooled Multi-Tenant SaaS Data with Amazon DynamoDB.

Wählen Sie zwischen Amazon RDS und Aurora

In den meisten Fällen empfehlen wir, Aurora PostgreSQL-kompatibel über Amazon RDS for PostgreSQL zu verwenden. Die folgende Tabelle zeigt die Faktoren, die Sie bei der Entscheidung zwischen diesen beiden Optionen berücksichtigen sollten.

DBMS-Komponente	Amazon RDS für PostgreSQL	Aurora PostgreSQL-kompatibel
Skalierbarkeit	Replikationsverzögerung von Minuten, maximal 5 Read Replicas	Replikationsverzögerung unter einer Minute (in der Regel weniger als 1 Sekunde bei globalen Datenbanken), maximal 15 Read Replicas
Wiederherstellung nach einem Absturz	Checkpoints im Abstand von 5 Minuten (standardmäßig) können die Datenbankleistung beeinträchtigen	Asynchrone Wiederherstellung mit parallel Threads für eine schnelle Wiederherstellung
Failover	60-120 Sekunden zusätzlich zur Wiederherstellungszeit nach einem Absturz	Normalerweise etwa 30 Sekunden (einschließlich Wiederherstellung nach einem Absturz)
Speicherung	Maximaler IOPS von 256.000	IOPS, die nur durch die Größe und Kapazität der Aurora-Instance eingeschränkt sind
Hohe Verfügbarkeit und Disaster Recovery	Zwei Availability Zones mit einer Standby-Instanz, regionsübergreifendem Failover zum Lesen von Replikaten oder kopierten Backups	Standardmäßig drei Availability Zones, regionsübergreifendes Failover mit globalen Aurora-Datenbanken, Schreibweiterleitung AWS-Regionen für Active-Active-Konfigurationen
Backup	Während des Backup-Fensters kann sich dies auf die Leistung auswirken	Automatische inkrementelle Backups, keine Auswirkungen auf die Leistung
Klassen von Datenbank-Instanzen	Liste der Amazon RDS-Instance-Klassen anzeigen	Liste der Aurora-Instanzklassen anzeigen

In allen in der vorherigen Tabelle beschriebenen Kategorien ist Aurora PostgreSQL-kompatibel normalerweise die bessere Option. Amazon RDS for PostgreSQL könnte jedoch für kleine bis mittlere Workloads immer noch sinnvoll sein, da es eine größere Auswahl an Instance-Klassen bietet, die auf Kosten des robusteren Funktionsumfangs von Aurora möglicherweise eine kostengünstigere Option darstellen.