Überblick über globale Tabellen

Wichtige Fakten

• Es gibt zwei Versionen globaler Tabellen: Version 2017.11.29 (Legacy) (manchmal als v1 bezeichnet) und Version 2019.11.21 (aktuell) (manchmal auch als v2 bezeichnet). Dieses Handbuch konzentriert sich ausschließlich auf die aktuelle Version.

• DynamoDB (ohne globale Tabellen) ist ein regionaler Dienst, was bedeutet, dass er hochverfügbar und von Natur aus widerstandsfähig gegen Infrastrukturausfälle ist, einschließlich des Ausfalls einer gesamten Availability Zone. Eine DynamoDB-Tabelle mit einer Region ist für eine Verfügbarkeit von 99,99% konzipiert. Weitere Informationen finden Sie im DynamoDB Service Level Agreement (SLA).

• Eine globale DynamoDB-Tabelle repliziert ihre Daten zwischen zwei oder mehr Regionen. Eine DynamoDB-Tabelle mit mehreren Regionen ist für eine Verfügbarkeit von 99,999% konzipiert. Bei richtiger Planung können globale Tabellen dazu beitragen, eine Architektur zu schaffen, die auch regionalen Ausfällen standhält.

• In DynamoDB gibt es keinen globalen Endpunkt. Alle Anfragen werden an einen regionalen Endpunkt gestellt, der auf die globale Tabelleninstanz zugreift, die in dieser Region lokal ist.

• Aufrufe von DynamoDB sollten nicht regionsübergreifend erfolgen. Es hat sich bewährt, dass eine Anwendung, die in einer Region gehostet ist, direkt nur auf den lokalen DynamoDB-Endpunkt für ihre Region zugreift. Wenn Probleme innerhalb einer Region (in der DynamoDB-Ebene oder im umgebenden Stack) festgestellt werden, sollte der Endbenutzerdatenverkehr an einen anderen Anwendungsendpunkt weitergeleitet werden, der in einer anderen Region gehostet wird. Globale Tabellen stellen sicher, dass die in jeder Region gehostete Anwendung Zugriff auf dieselben Daten hat.

Konsistenzmodi

Wenn Sie eine globale Tabelle erstellen, konfigurieren Sie ihren Konsistenzmodus. Globale Tabellen unterstützen zwei Konsistenzmodi: Multi-Region Eventual Consistency (MREC) und Multi-Region Strong Consistency (MRSC), die im Juni 2025 eingeführt wurden.

Wenn Sie beim Erstellen einer globalen Tabelle keinen Konsistenzmodus angeben, wird für die globale Tabelle standardmäßig MREC verwendet. Eine globale Tabelle kann keine Replikate enthalten, die mit unterschiedlichen Konsistenzmodi konfiguriert sind. Sie können den Konsistenzmodus einer globalen Tabelle nach ihrer Erstellung nicht ändern.

Die wichtigsten Fakten zu MREC

• Globale Tabellen, die MREC verwenden, verwenden ein aktiv-aktives Replikationsmodell. Aus Sicht von DynamoDB ist die Tabelle in jeder Region gleichberechtigt, Lese- und Schreibanforderungen anzunehmen. Nach Erhalt einer Schreibanforderung repliziert die lokale Replikattabelle den Schreibvorgang im Hintergrund in andere beteiligte Remote-Regionen.

• Elemente werden einzeln repliziert. Elemente, die innerhalb einer einzigen Transaktion aktualisiert werden, werden möglicherweise nicht zusammen repliziert.

• Jede Tabellenpartition in der Quellregion repliziert ihre Schreiboperationen parallel zu jeder anderen Partition. Die Reihenfolge der Schreibvorgänge innerhalb einer Remote-Region stimmt möglicherweise nicht mit der Reihenfolge der Schreibvorgänge in der Quellregion überein. Weitere Informationen zu Tabellenpartitionen finden Sie im Blogbeitrag Skalierung von DynamoDB: Wie sich Partitionen, Hotkeys und Split for Heat auf die Leistung auswirken.

• Ein neu geschriebenes Element wird in der Regel innerhalb einer Sekunde auf alle Replikattabellen verteilt. Die Verteilung in nahegelegene Regionen erfolgt tendenziell schneller.

• Amazon CloudWatch stellt für jedes Regionspaar eine ReplicationLatency Metrik bereit. Sie wird berechnet, indem die eingehenden Artikel betrachtet, ihre Ankunftszeit mit der ursprünglichen Schreibzeit verglichen und ein Durchschnitt berechnet wird. Die Zeitangaben werden innerhalb CloudWatch der Quellregion gespeichert. Die Anzeige der durchschnittlichen und maximalen Zeiten kann nützlich sein, um die durchschnittliche Verzögerung bei der Replikation und im schlimmsten Fall zu ermitteln. Für diese Latenz gibt es kein SLA.

• Wenn ein einzelnes Element etwa zur gleichen Zeit (innerhalb dieses ReplicationLatency Fensters) in zwei verschiedenen Regionen aktualisiert wird und der zweite Schreibvorgang vor der Replikation des ersten Schreibvorgangs erfolgt, besteht die Gefahr von Schreibkonflikten. Globale Tabellen, die MREC verwenden, lösen solche Konflikte mithilfe eines Last-Writer-Wins-Mechanismus, der auf dem Zeitstempel der Schreibvorgänge basiert. Die erste Operation „verliert“ an die zweite Operation. Diese Konflikte werden nicht in CloudWatch oder aufgezeichnet AWS CloudTrail.

• Jedes Element verfügt über einen Zeitstempel für den letzten Schreibvorgang, der als private Systemeigenschaft gespeichert wird. Der letzte Writer-Wins-Ansatz wird mithilfe eines bedingten Schreibvorgangs implementiert, bei dem der Zeitstempel des eingehenden Elements größer sein muss als der Zeitstempel des vorhandenen Elements.

• Eine globale Tabelle repliziert alle Elemente in alle beteiligten Regionen. Wenn Sie unterschiedliche Replikationsbereiche verwenden möchten, können Sie mehrere globale Tabellen erstellen und jeder Tabelle verschiedene teilnehmende Regionen zuweisen.

• Die lokale Region akzeptiert Schreibvorgänge, auch wenn die Replikatregion offline ist oder ReplicationLatency wächst. Die lokale Tabelle versucht weiterhin, Elemente in die Remote-Tabelle zu replizieren, bis dies für jedes Element erfolgreich ist.

• In dem unwahrscheinlichen Fall, dass eine Region vollständig offline geht und sie später wieder online ist, werden alle ausstehenden ausgehenden und eingehenden Replizierungen erneut versucht. Es sind keine besonderen Maßnahmen erforderlich, um die Tabellen wieder zu synchronisieren. Der „Last Writer Win“ -Mechanismus stellt sicher, dass die Daten letztendlich konsistent werden.

• Sie können einer DynamoDB-MREC-Tabelle jederzeit eine neue Region hinzufügen. DynamoDB übernimmt die anfängliche Synchronisierung und die laufende Replikation. Sie können auch eine Region (auch die ursprüngliche Region) entfernen. Dadurch wird die lokale Tabelle in dieser Region gelöscht.

Die wichtigsten Fakten über MRSC

• Globale Tabellen, die MRSC verwenden, verwenden ebenfalls ein aktiv-aktives Replikationsmodell. Aus Sicht von DynamoDB ist die Tabelle in jeder Region gleichberechtigt, Lese- und Schreibanforderungen anzunehmen. Elementänderungen in einem globalen MRSC-Tabellenreplikat werden synchron in mindestens eine andere Region repliziert, bevor der Schreibvorgang eine erfolgreiche Antwort zurückgibt.

• Stark konsistente Lesevorgänge für ein beliebiges MRSC-Replikat geben immer die neueste Version eines Elements zurück. Bei bedingten Schreibvorgängen wird der Bedingungsausdruck immer mit der neuesten Version eines Elements verglichen. Aktualisierungen beziehen sich immer auf die neueste Version eines Elements.

• Konsistente Lesevorgänge auf einem MRSC-Replikat schließen möglicherweise keine Änderungen ein, die kürzlich in einer anderen Region vorgenommen wurden, und schließen möglicherweise nicht einmal Änderungen ein, die kürzlich in derselben Region aufgetreten sind.

• Ein Schreibvorgang schlägt mit einer ReplicatedWriteConflictException Ausnahme fehl, wenn versucht wird, ein Element zu ändern, das bereits in einer anderen Region geändert wird. Schreibvorgänge, die mit der ReplicatedWriteConflictException Ausnahme fehlschlagen, können wiederholt werden und sind erfolgreich, wenn das Element in einer anderen Region nicht mehr geändert wird.

• Bei MRSC sind die Latenzen bei Schreibvorgängen und bei stark konsistenten Lesevorgängen höher. Diese Operationen erfordern eine regionsübergreifende Kommunikation. Diese Kommunikation führt tendenziell zu einer erhöhten Latenz, die je nach der Round-Trip-Latenz zwischen der Region, auf die zugegriffen wird, und der nächstgelegenen Region, die an der globalen Tabelle teilnimmt, zunimmt. (Weitere Informationen finden Sie in der AWS re:Invent 2024-Präsentation Multi-Region strong consistency with Amazon DynamoDB global tables.) Schließlich kommt es bei konsistenten Lesevorgängen zu keiner zusätzlichen Latenz. Es gibt ein Open-Source-Testtool, mit dem Sie diese Latenzen experimentell mit Ihren Regionen berechnen können.

• Elemente werden einzeln repliziert. Globale Tabellen, die MRSC verwenden, unterstützen die Transaktion nicht. APIs

• Eine globale MRSC-Tabelle muss in genau drei Regionen bereitgestellt werden. Sie können eine globale MRSC-Tabelle mit drei Replikaten oder mit zwei Replikaten und einem Zeugen konfigurieren. Ein Zeuge ist eine Komponente einer globalen MRSC-Tabelle, die aktuelle Daten enthält, die in globale Tabellenreplikate geschrieben wurden. Ein Zeuge bietet eine optionale Alternative zu einem vollständigen Replikat und unterstützt gleichzeitig die Verfügbarkeitsarchitektur von MRSC. Sie können für einen Zeugen keine Lese- oder Schreibvorgänge ausführen. Für einen Zeugen fallen keine Speicher- oder Schreibkosten an. Ein Zeuge befindet sich in einer anderen Region als die beiden Kopien.

• Um eine globale MRSC-Tabelle zu erstellen, fügen Sie ein Replikat und einen Zeugen hinzu oder fügen zwei Replikate zu einer vorhandenen DynamoDB-Tabelle hinzu, die keine Daten enthält. Sie können einer vorhandenen globalen MRSC-Tabelle keine zusätzlichen Replikate hinzufügen. Sie können kein einzelnes Replikat oder einen Zeugen aus einer globalen MRSC-Tabelle löschen. Sie können zwei Replikate oder ein Replikat und einen Zeugen aus einer globalen MRSC-Tabelle löschen. Im zweiten Szenario wird das verbleibende Replikat in eine DynamoDB-Tabelle mit einer einzigen Region konvertiert.

• Sie können anhand der API-Ausgabe ermitteln, ob für eine globale MRSC-Tabelle ein Zeuge konfiguriert ist und in welcher Region er konfiguriert ist. DescribeTable Der Zeuge gehört DynamoDB und wird von diesem verwaltet. Er erscheint nicht in Ihrer Region, AWS-Konto in der er konfiguriert ist.

• Die globalen MRSC-Tabellen sind in den folgenden Regionsgruppen verfügbar:

  • Gruppe US-Regionen: USA Ost (Nord-Virginia), USA Ost (Ohio), USA West (Oregon)

  • EU-Regionalgruppe: Europa (Irland), Europa (London), Europa (Paris), Europa (Frankfurt)

  • AP-Region: Asien-Pazifik (Tokio), Asien-Pazifik (Seoul) und Asien-Pazifik (Osaka)

• Globale MRSC-Tabellen können sich nicht über Regionsgruppen erstrecken. Beispielsweise kann eine globale MRSC-Tabelle keine Replikate aus Regionsgruppen der USA und der EU enthalten.

• Time to Live (TTL) wird für globale MRSC-Tabellen nicht unterstützt.

• Lokale Sekundärindizes (LSIs) werden für globale MRSC-Tabellen nicht unterstützt.

• CloudWatch Contributor Insights-Informationen werden nur für die Region gemeldet, in der ein Vorgang stattgefunden hat.

• Die lokale Region akzeptiert alle Lese- und Schreibvorgänge, solange eine zweite Region, die ein Replikat oder einen Zeugen hostet, verfügbar ist, um das Quorum herzustellen. Wenn eine zweite Region nicht verfügbar ist, kann die lokale Region nur eventuell konsistente Lesevorgänge verarbeiten.

• In dem unwahrscheinlichen Fall, dass eine Region vollständig offline geht und sie später wieder online ist, catch sie automatisch auf. Schreibvorgänge und stark konsistente Lesevorgänge geben Fehler zurück, bis der Vorgang abgeschlossen ist. Bei konsistenten Lesevorgängen werden jedoch die Daten zurückgegeben, die bisher in die Region übertragen wurden, wobei das übliche lokale Konsistenzverhalten zwischen dem Leader-Knoten und den lokalen Replikaten vorherrscht. Es sind keine besonderen Maßnahmen erforderlich, um die Tabellen wieder zu synchronisieren

Anwendungsfälle

Die globalen MREC-Tabellen bieten folgende Vorteile:

• Lesevorgänge mit niedrigerer Latenz. Sie können eine Kopie der Daten näher am Endbenutzer platzieren, um die Netzwerklatenz bei Lesevorgängen zu reduzieren. Die Daten werden so aktuell gehalten wie der ReplicationLatency Wert.

• Schreibvorgänge mit niedrigerer Latenz. Ein Endbenutzer kann in eine Region in der Nähe schreiben, um die Netzwerklatenz und die Zeit bis zum Abschluss des Schreibvorgangs zu reduzieren. Der Schreibverkehr muss sorgfältig weitergeleitet werden, um sicherzustellen, dass keine Konflikte auftreten. Techniken für das Routing werden in einem späteren Abschnitt behandelt.

• Nahtlose Migration von Regionen. Sie können eine neue Region hinzufügen und dann die alte Region löschen, um eine Bereitstellung von einer Region in eine andere zu migrieren, ohne dass es zu Ausfallzeiten auf der Datenebene kommt.

Sowohl die globalen MREC- als auch die MRSC-Tabellen bieten diesen Vorteil:

• Verbesserte Resilienz und Notfallwiederherstellung. Wenn in einer Region Leistungseinbußen oder ein vollständiger Ausfall auftritt, können Sie sie evakuieren (d. h. einige oder alle Anfragen, die an diese Region gerichtet sind, verschieben). Durch die Verwendung globaler Tabellen wird der DynamoDB-SLA für die monatliche Verfügbarkeit in Prozent von 99,99% auf 99,999% erhöht. Die Verwendung von MREC unterstützt ein in Sekunden gemessenes Recovery Point Objective (RPO) und Recovery Time Objective (RTO). Bei Verwendung von MRSC wird ein RPO von Null unterstützt.

  Zum Beispiel präsentierte Fidelity Investments auf der re:Invent 2022, wie sie globale DynamoDB-Tabellen für ihr Order Management System verwenden. Ihr Ziel war es, eine zuverlässige Verarbeitung mit niedriger Latenz in einem Umfang zu erreichen, den sie mit der Verarbeitung vor Ort nicht erreichen konnten, und gleichzeitig die Widerstandsfähigkeit gegenüber Ausfällen in der Availability Zone und bei regionalen Ausfällen aufrechtzuerhalten.

Wenn Ihr Ziel Resilienz und Disaster Recovery ist, haben MRSC-Tabellen höhere Schreiblatenzen und höhere, stark konsistente Leselatenzen, unterstützen aber ein RPO von Null. Globale MREC-Tabellen unterstützen ein RPO, das der Replikationsverzögerung zwischen Replikaten entspricht — in der Regel einige Sekunden, abhängig von den Replikatregionen. Weitere Informationen finden Sie unter Konsistenzmodi in der DynamoDB-Dokumentation.