Die Entscheidung zwischen Amazon Aurora, Amazon Relational Database Service (Amazon RDS), Amazon DynamoDB, Amazon ElastiCache und Amazon Redshift beginnt mit einer grundlegenden Festlegung. Wir müssen definieren, wie die Workload Daten liest und schreibt und welche Garantien sie hinsichtlich Konsistenz, Latenz, Verfügbarkeit und Wiederherstellung bieten muss. In diesem Kurs entwickeln wir einen reproduzierbaren Rahmen, der diese Anforderungen in eine begründbare und überprüfbare Datenbankentscheidung überführt.
Dieser Kurs konzentriert sich auf fünf verwaltete AWS-Datendienste und die für sie geeigneten Workloads. Amazon Aurora und Amazon RDS sind für die Online-Transaktionsverarbeitung (OLTP) in relationalen Datenbanken konzipiert. Amazon DynamoDB eignet sich für Key-Value-Zugriffsmuster mit vorhersagbarer Leistung im einstelligen Millisekundenbereich, auch bei hoher Skalierung. Amazon ElastiCache ist ein In-Memory-Cache, der Datenkopien speichert, anstatt als primäre Datenquelle (System of Record) zu dienen. Amazon Redshift ist für Analyse-Workloads ausgelegt, die große Datensätze scannen und aggregieren.
Dabei berücksichtigen wir auch die AWS-Struktur. Eine Region ist ein geografisches Gebiet, in dem AWS mehrere voneinander isolierte Rechenzentren betreibt. Eine Availability Zone (Verfügbarkeitszone) ist ein isolierter Standort innerhalb einer Region. Viele Funktionen für Datendauerhaftigkeit und Verfügbarkeit hängen davon ab, wie ein Dienst mehrere Availability Zones innerhalb einer Region nutzt.
Betrachten wir nun, wie sich diese fünf Dienste in das Spektrum aus Transaktionsverarbeitung, Caching und Analytik einordnen lassen.
Wir werden in jeder Lektion denselben Entscheidungszyklus anwenden. Zunächst legen wir die Zugriffsmuster und das Datenmodell fest. Anschließend ordnen wir diese Anforderungen einem entsprechenden Dienstmechanismus zu. Danach benennen wir die Abwägungen hinsichtlich Kosten, betrieblicher Verantwortung und Fehlerverhalten. Schließlich untermauern wir die Entscheidung mit beobachtbaren Belegen statt mit bloßen Annahmen.
Die Belege müssen zu dem Systembereich passen, den wir untersuchen. Metriken und Protokolle zeigen, was während der tatsächlichen Laufzeit geschehen ist. Statische Analysen und Konfigurationsprüfungen zeigen lediglich auf, was bei einer bestimmten Konfiguration geschehen könnte. Eine fundierte Entscheidung stützt sich auf mindestens einen Laufzeitindikator, der unsere Annahmen widerlegen kann.
Veranschaulichen wir uns den Weg von der Anforderung über den Mechanismus bis hin zum Beleg, den wir immer wieder durchspielen werden.