So funktionieren globale DynamoDB-Tabellen

In den folgenden Abschnitten werden die Konzepte und das Verhalten globaler Tabellen in Amazon DynamoDB beschrieben.

Konzepte

Globale Tabellen sind ein DynamoDB-Feature, mit dem Tabellendaten über AWS-Regionen repliziert werden können.

Eine Replikattabelle (oder kurz ein Replikat) ist eine einzelne DynamoDB-Tabelle, die als Teil einer globalen Tabelle fungiert. Eine globale Tabelle besteht aus zwei oder mehr Replikattabellen in verschiedenen AWS-Regionen. Jede globale Tabelle kann nur über eine Replikattabelle je AWS-Region verfügen. Alle Replikate in einer globalen Tabelle verwenden denselben Tabellennamen, dasselbe Primärschlüsselschema und dieselben Elementdaten.

Wenn eine Anwendung Daten in eine Replikattabelle in einer Region schreibt, verteilt DynamoDB den Schreibvorgang automatisch auf die anderen Replikattabellen in der globalen Tabelle. Weitere Informationen über die ersten Schritte mit globalen Tabellen finden Sie unter Tutorials: Erstellen von globalen Tabellen.

Versionen

Es gibt zwei Versionen von globalen DynamoDB-Tabellen: Version 2019.11.21 (Aktuell) und Version 2017.11.29 (Legacy). Sie sollten nach Möglichkeit die Version 2019.11.21 (Aktuell) verwenden. Die Informationen in diesem Abschnitt der Dokumentation gelten für die Version 2019.11.21 (Aktuell). Weitere Informationen finden Sie unter Ermitteln der Version einer globalen Tabelle.

Verfügbarkeit

Globale Tabellen tragen zur Verbesserung der Geschäftskontinuität bei, da sie die Implementierung einer hoch verfügbaren Architektur für mehrere Regionen erleichtern. Wenn eine Workload in einer einzelnen AWS-Region beeinträchtigt ist, können Sie den Datenverkehr der Anwendung auf eine andere Region verschieben und Lese- und Schreibvorgänge in einer anderen Replikattabelle in derselben globalen Tabelle ausführen.

Jede Replikattabelle in einer globalen Tabelle bietet dieselbe Stabilität und Verfügbarkeit wie eine DynamoDB-Tabelle mit einer Region. Globale Tabellen bieten ein Service Level Agreement (SLA) mit einer Verfügbarkeit von 99,999 %, im Gegensatz zur Verfügbarkeit von 99,99 % bei Tabellen mit einer einzelnen Region.

Konsistenzmodi

Sie können bei der Erstellung einer globalen Tabelle den Konsistenzmodus konfigurieren. Globale Tabellen unterstützen zwei Konsistenzmodi: Multi-Region Eventual Consistency (MREC) und Multi-Region Strong Consistency (MRSC).

Wenn Sie beim Erstellen einer globalen Tabelle keinen Konsistenzmodus angeben, wird für die globale Tabelle standardmäßig der MREC-Modus verwendet. Replikate, die mit unterschiedlichen Konsistenzmodi konfiguriert wurden, sind in einer globalen Tabelle nicht zulässig. Sie können den Konsistenzmodus einer globalen Tabelle nach der Erstellung nicht mehr ändern.

Multi-Region Eventual Consistency (MREC)

Der Standardmodus für globale Tabellen ist der MREC-Modus (Multi-Region Eventual Consistency). Elementänderungen im Replikat einer globalen MREC-Tabelle werden asynchron für alle anderen Replikate repliziert, normalerweise innerhalb von maximal einer Sekunde. In dem unwahrscheinlichen Fall, dass ein Replikat in einer globalen MREC-Tabelle isoliert ist oder beeinträchtigt wird, werden alle Daten, die noch nicht in andere Regionen repliziert wurden, repliziert, sobald das Replikat fehlerfrei ist.

Wenn dasselbe Element in mehreren Regionen gleichzeitig geändert wird, löst DynamoDB den Konflikt, indem die Änderung mit dem neuesten internen Zeitstempel pro Element verwendet wird; diese Konfliktlösungsmethode wird als „Last Writer Wins“ bezeichnet. Letztendlich stimmt ein Element in allen Replikaten mit der Version überein, die beim letzten Schreibvorgang erstellt wurde.

Strikt konsistente Lesevorgänge geben die jeweils aktuelle Version eines Elements zurück, wenn dieses zuletzt in der Region aktualisiert wurde, in der der Lesevorgang stattgefunden hat. Hierbei können jedoch veraltete Daten zurückgegeben werden, wenn das Element zuletzt in einer anderen Region aktualisiert wurde. Bei bedingten Schreibvorgängen wird der Bedingungsausdruck mit der Version des Elements in der Region verglichen.

Sie erstellen eine globale MREC-Tabelle, indem Sie einer vorhandenen DynamoDB-Tabelle ein Replikat hinzufügen. Das Hinzufügen eines Replikats hat keine Auswirkungen auf die Leistung vorhandener DynamoDB-Tabellen mit einer einzigen Region oder von Replikaten globaler Tabellen. Sie können einer globalen MREC-Tabelle Replikate hinzufügen, um die Anzahl der Regionen zu erhöhen, in denen Daten repliziert werden, oder Replikate aus einer globalen MREC-Tabelle entfernen, wenn sie nicht mehr benötigt werden. Eine globale MREC-Tabelle kann ein Replikat in jeder Region haben, in der DynamoDB verfügbar ist, und sie kann so viele Replikate enthalten, wie es Regionen in der AWS-Partition gibt.

Multi-Region Strong Consistency (MRSC)

Sie können bei der Erstellung einer globalen Tabelle den MRSC-Modus (Multi-Region Strong Consistency) konfigurieren. Elementänderungen im Replikat einer globalen MRSC-Tabelle werden synchron in mindestens eine andere Region repliziert, bevor der Schreibvorgang eine erfolgreiche Antwort zurückgibt. Wenn Sie eine bestehende Tabelle mit einer einzigen Region in eine globale MRSC-Tabelle umwandeln, müssen Sie sicherstellen, dass die Tabelle leer ist, bis die Konvertierung abgeschlossen ist, um eine korrekte Initialisierung und Replikationseinrichtung sicherzustellen.

Strikt konsistente Lesevorgänge für ein beliebiges MRSC-Replikat geben immer die neueste Version eines Elements zurück. Bei bedingten Schreibvorgängen wird immer der Bedingungsausdruck mit der aktuellen Version des Elements verglichen.

Bei einem Schreibvorgang tritt der Fehler ReplicatedWriteConflictException auf, wenn versucht wird, ein Element zu ändern, das bereits in einer anderen Region geändert wird. Schreibvorgänge, bei denen der Fehler ReplicatedWriteConflictException auftritt, können wiederholt werden und sind erfolgreich, wenn das Element in einer anderen Region nicht mehr geändert wird.

Sie können eine globale MRSC-Tabelle mit drei Replikaten oder zwei Replikaten und einem Witness konfigurieren. Ein Witness ist eine Komponente einer globalen MRSC-Tabelle, die Daten enthält, die in Replikate von globalen Tabellen geschrieben wurden. Er bietet eine optionale Alternative zu einem vollständigen Replikat und unterstützt gleichzeitig die hoch verfügbare Architektur von MRSC-Tabellen. Sie können für einen Witness keine Lese- oder Schreibvorgänge ausführen. Ein Witness befindet sich in einer anderen Region als die beiden Replikate.

Wenn Sie eine globale MRSC-Tabelle erstellen, wählen Sie bei ihrer Erstellung die Regionen sowohl für die Bereitstellung der Replikate als auch für den Witness aus. Sie können anhand der Ausgabe der DescribeTable-API bestimmen, ob und in welcher Region für eine globale MRSC-Tabelle ein Witness konfiguriert ist. Der Witness gehört DynamoDB und wird von DynamoDB verwaltet und erscheint nicht im AWS-Konto der Region, in der er konfiguriert wurde.

Eine globale MRSC-Tabelle muss in genau drei Regionen bereitgestellt werden. Sie erstellen eine globale MRSC-Tabelle, indem Sie einer vorhandenen DynamoDB-Tabelle, die keine Daten enthält, ein Replikat und einen Witness oder zwei Replikate hinzufügen. Sie können einer vorhandenen globalen MRSC-Tabelle keine zusätzlichen Replikate hinzufügen. Ein einzelnes Replikat oder ein Witness kann nicht aus einer globalen MRSC-Tabelle gelöscht werden. Sie können zwei Replikate oder ein Replikat und einen Witness aus einer globalen MRSC-Tabelle löschen und das verbleibende Replikat in eine DynamoDB-Tabelle mit einer einzigen Region umwandeln.

Für globale MRSC-Tabellen gelten die folgenden Überlegungen:

Auswählen eines Konsistenzmodus

Das Hauptkriterium für die Auswahl eines Konsistenzmodus für mehrere Regionen ist, ob die Anwendung Schreibvorgängen mit geringer Latenz und strikt konsistente Lesevorgänge oder der globalen strikten Konsistenz Priorität einräumt.

Globale MREC-Tabellen weisen im Vergleich zu globalen MRSC-Tabellen Schreib- und strikt konsistente Lesevorgänge mit geringen Latenzen auf. Globale MREC-Tabellen können ein Recovery Point Objective (RPO) unterstützen, das der verzögerten Replikation zwischen Replikaten entspricht, die je nach Region in der Regel einige Sekunden beträgt.

In folgenden Fällen sollten Sie den MREC-Modus verwenden:

Globale MRSC-Tabellen weisen im Vergleich zu globalen MREC-Tabellen Schreib- und strikt konsistente Lesevorgänge mit höheren Latenzen auf. Globale MRSC-Tabellen unterstützen einen Recovery Point Objective (RPO) von null.

In folgenden Fällen sollten Sie den MRSC-Modus verwenden:

Überwachen globaler Tabellen

Globale Tabellen mit MREC-Konfiguration veröffentlichen die ReplicationLatency-Metrik in CloudWatch. Diese Metrik misst die verstrichene Zeit zwischen dem Schreiben eines Elements in eine Replikattabelle und dem Erscheinen dieses Elements in einem anderen Replikat in der globalen Tabelle. ReplicationLatency wird in Millisekunden ausgedrückt und für jedes Paar aus Quell- und Zielregion ausgegeben.

Die typischen ReplicationLatency-Werte hängen von der Entfernung zwischen den ausgewählten AWS-Regionen sowie von anderen Variablen wie Workload-Typ und Durchsatz ab. Beispiel: Ein Quellreplikat in der Region USA West (Nordkalifornien) (us-west-1) weist im Vergleich zur Region Afrika (Kapstadt) (af-south-1) einen niedrigeren Wert für ReplicationLatency auf als die Region USA West (Oregon) (us-west-2).

Ein erhöhter Wert für ReplicationLatency könnte darauf hinweisen, dass Updates von einem Replikat nicht in einem angemessenen Zeitraum an andere Replikattabellen verteilt werden. In diesem Fall können Sie die Lese- und Schreibaktivitäten der Anwendung vorübergehend an eine andere AWS-Region umleiten.

Globale Tabellen mit MRSC-Konfiguration veröffentlichen keine ReplicationLatency-Metrik.

Testen mit Fehlerinjektionen

Globale Tabellen lassen sich auch in den AWS-Fehlerinjektions-Service (AWS FIS) integrieren, wo Fehlerinjektionstests für die Workloads von globalen Tabellen durchgeführt werden. Auf diese Weise können Sie die Reaktion einer Anwendung auf die simulierte Isolation einer Region testen, indem Sie die Replikation zu und von einem ausgewählten Replikat unterbrechen. Weitere Informationen finden Sie unter Anhalten der Replikation globaler Tabellen.

Time to Live (TTL)

In globalen Tabellen mit MREC-Konfiguration kann die Konfiguration von Time To Live (TTL) gelöscht werden. Die TTL-Einstellungen werden automatisch für alle Replikate einer globalen Tabelle synchronisiert. Wenn TTL ein Element aus einem Replikat in einer Region löscht, wird der Löschvorgang auf alle anderen Replikate in der globalen Tabelle repliziert. TTL verbraucht keine Schreibkapazität; das Löschen von TTL wird Ihnen in der Region, in der der Löschvorgang stattgefunden hat, nicht in Rechnung gestellt. In allen anderen Regionen, deren globale Tabelle ein Replikat enthält, wird Ihnen jedoch der replizierte Löschvorgang in Rechnung gestellt.

Die Replikation eines TTL-Löschvorgangs verbraucht Schreibkapazität in den Replikaten, in die der Löschvorgang repliziert wird. Replikate, die für bereitgestellte Kapazität konfiguriert sind, können Anfragen drosseln, wenn die Kombination aus Schreibdurchsatz und TTL-Löschdurchsatz die bereitgestellte Schreibkapazität überschreitet.

Globale Tabellen mit MRSC-Konfiguration unterstützen die Konfiguration des TTL-Löschvorgangs nicht.

Streams

Globale Tabellen mit MREC-Konfiguration replizieren Änderungen, indem sie diese aus einem DynamoDB-Stream in einer Replikattabelle auslesen und auf alle anderen Replikattabellen anwenden. Streams sind daher standardmäßig für alle Replikate in einer globalen MREC-Tabelle aktiviert und können in diesen Replikaten nicht deaktiviert werden. Der MREC-Replikationsprozess kann mehrere Änderungen in einem kurzen Zeitraum zu einem einzigen replizierten Schreibvorgang kombinieren, was dazu führt, dass der Stream jedes Replikats Datensätze enthält, die sich geringfügig unterscheiden. Streams-Datensätze in MREC-Replikaten werden immer elementweise sortiert, wobei die Reihenfolge zwischen den Elementen sich von Replikat zu Replikat unterscheiden kann.

Globale Tabellen mit MRSC-Konfiguration verwenden keine DynamoDB Streams für die Replikation, sodass Streams in MRSC-Replikaten standardmäßig nicht aktiviert sind. Streams können in einem MRSC-Replikat aktiviert werden. Streams-Datensätze in MRSC-Replikaten sind für jedes Replikat identisch, auch in Bezug auf ihre Reihenfolge.

Wenn Sie eine Anwendung schreiben möchten, die Streams-Datensätze für Änderungen verarbeitet, die in einer bestimmten Region, aber nicht in anderen Regionen in einer globalen Tabelle vorgenommen wurden, können Sie jedem Element ein Attribut hinzufügen, das definiert, in welcher Region die Änderung für dieses Element stattgefunden hat. Sie können dieses Attribut verwenden, um Streams-Datensätze nach Änderungen zu filtern, die in anderen Regionen aufgetreten sind und hierzu auch Lambda-Ereignisfilter verwenden, um Lambda-Funktionen nur für Änderungen in einer bestimmten Region aufzurufen.

Transaktionen

In einer globalen Tabelle mit MREC-Konfiguration sind DynamoDB-Transaktionsoperationen (TransactWriteItems und TransactGetItems) nur innerhalb der Region, in der der Vorgang aufgerufen wurde, unteilbar. Schreibtransaktionen werden nicht als Einheit regionsübergreifend repliziert, was bedeutet, dass nur einige Schreibvorgänge in einer Transaktion zu einem bestimmten Zeitpunkt durch Lesevorgänge in anderen Replikaten zurückgegeben werden können.

Wenn Sie beispielsweise eine globale Tabelle mit Replikaten in den Regionen USA Ost (Ohio) und USA West (Oregon) nutzen und eine TransactWriteItems-Operation in der Region USA Ost (Ohio) durchführen, sind unter Umständen partiell durchgeführte Transaktionen in der Region USA West (Oregon) zu beobachten, während die Änderungen repliziert werden. Die Änderungen werden erst in die anderen Regionen repliziert, nachdem sie in der Quellregion in die Datenbank eingetragen wurden.

Globale Tabellen mit MRSC-Konfiguration unterstützen keine Transaktionsvorgänge und geben einen Fehler zurück, wenn solche Operationen in einem MRSC-Replikat aufgerufen werden.

Lese- und Schreibdurchsatz

Eine Replikation verbraucht Schreibkapazität. Replikate, die für bereitgestellte Kapazität konfiguriert sind, können Anfragen drosseln, wenn die Kombination aus Schreibdurchsatz und Replikation die bereitgestellte Schreibkapazität überschreitet. Die Schreibkapazität im On-Demand-Modus wird für alle Replikate in einer globalen Tabelle synchronisiert. In globalen Tabellen, die für bereitgestellte Kapazität konfiguriert sind, werden Auto-Scaling-Einstellungen zwischen Replikaten synchronisiert. Die tatsächlich bereitgestellte Schreibkapazität kann je nach verbrauchtem Schreibdurchsatz von Replikat zu Replikat variieren.

Sie können die Einstellungen für die Lesekapazitätseinstellungen für jedes Replikat einer globalen Tabelle unabhängig voneinander konfigurieren. Beim Hinzufügen eines Replikats zu einer globalen Tabelle wird die Lesekapazität der Quelltabelle oder des Replikats als Anfangswert verwendet, sofern kein Überschreibungswert angegeben wurde.

Synchronisierung von Einstellungen

Einstellungen in globalen DynamoDB-Tabellen sind Konfigurationsparameter, mit denen verschiedene Aspekte des Tabellenverhaltens und der Replikation gesteuert werden können. Diese Einstellungen werden über die APIs der DynamoDB-Steuerebene verwaltet und können beim Erstellen oder Ändern globaler Tabellen konfiguriert werden. In globale Tabellen werden bestimmte Einstellungen für alle Replikate automatisch synchronisiert, um die Konsistenz zu wahren und gleichzeitig Flexibilität für regionsspezifische Optimierungen zu ermöglichen. Wenn Sie wissen, welche Einstellungen synchronisiert werden und wie sich diese verhalten, können Sie Ihre globale Tabelle effizient konfigurieren. Je nach Art ihrer replikatsübergreifenden Synchronisation lassen sich diese Einstellungen in drei Hauptkategorien unterteilen.

Die folgenden Einstellungen werden immer zwischen Replikaten in einer globalen Tabelle synchronisiert:

Die folgenden Einstellungen werden zwischen Replikaten synchronisiert, können jedoch für ein Replikat außer Kraft gesetzt werden:

Die folgenden Einstellungen werden niemals zwischen Replikaten in einer globalen Tabelle synchronisiert:

Alle anderen Einstellungen werden nicht zwischen Replikaten synchronisiert.

DynamoDB Accelerator (DAX)

Bei Schreibvorgängen in Replikate von globalen Tabellen wird DynamoDB unter Umgehung von DynamoDB Accelerator (DAX) direkt aktualisiert. In der Folge kann es zu veralteten DAX-Caches kommen, da der DAX-Cache nicht durch die Schreibvorgänge aktualisiert wird. DAX-Caches, die für Replikate von globalen Tabellen konfiguriert sind, werden erst bei Ablauf der TTL des Cache aktualisiert.

Überlegungen zur Verwaltung globaler Tabellen

Sie können eine Tabelle, die zum Hinzufügen des neuen Replikats einer globalen Tabelle verwendet wurde, erst 24 Stunden nach der Erstellung des neuen Replikats löschen.

Bei Deaktivierung einer AWS-Region, die Replikate von globalen Tabellen enthält, werden diese Replikate 20 Stunden nach der Deaktivierung der Region dauerhaft in Tabellen mit einer einzigen Region umgewandelt.