Verwenden von globalen Tabellen in DynamoDB - Amazon-DynamoDB
Wichtige FaktenWichtige Fakten zu MRECWichtige Fakten zu MRSCAnwendungsfälleFazit und Ressourcen

Verwenden von globalen Tabellen in DynamoDB

Globale Tabellen bauen auf der globalen Reichweite von Amazon DynamoDB auf, um Ihnen eine vollständig verwaltete, multiregionale und multiaktive Datenbank zur Verfügung zu stellen, die schnelle lokale Lese- und Schreibleistung für massiv skalierte, globale Anwendungen bietet. Globale Tabellen replizieren Ihre DynamoDB-Tabellen automatisch über Ihre gewünschten AWS-Regionen. Es sind keine Anwendungsänderungen erforderlich, da globale Tabellen die vorhandenen DynamoDB-APIs verwenden. Für die Verwendung von globalen Tabellen fallen keine Vorabkosten an und Sie müssen keine Verpflichtungen im Voraus eingehen. Sie zahlen nur für die tatsächlich genutzten Ressourcen.

Dieser Leitfaden erklärt, wie Sie globale DynamoDB-Tabellen effektiv nutzen können. Er enthält die wichtigsten Fakten über globale Tabellen, erklärt die wichtigsten Anwendungsfälle der Funktion, beschreibt die zwei Konsistenzmodi, stellt eine Systematik mit drei verschiedenen Schreibmodellen vor, die Sie in Betracht ziehen sollten, geht die vier wichtigsten Optionen für die Weiterleitung von Anforderungen durch, die Sie implementieren können, erörtert Möglichkeiten zur Evakuierung einer Region, die live ist, oder einer Region, die offline ist, erklärt, wie Sie über die Planung von Durchsatzkapazitäten nachdenken sollten, und enthält eine Checkliste mit Dingen, die Sie bei der Implementierung globaler Tabellen berücksichtigen sollten.

Dieser Leitfaden fügt sich in einen größeren Kontext von AWS-Multi-Region-Bereitstellungen ein, wie sie im Whitepaper AWS-Multi-Region-Grundlagen und im Video Designmuster für Datenausfallsicherheit mit AWS behandelt werden.

Themen

Wichtige Fakten zum Design von globalen DynamoDB-Tabellen

  • Es gibt zwei Versionen globaler Tabellen: die aktuelle Version Global Tables Version 2019.11.21 (Current) (manchmal als „V2“ bezeichnet) und Version 2017.11.29 (Legacy) der globalen Tabellen (manchmal als „V1“ bezeichnet). In diesem Leitfaden geht es ausschließlich um die aktuelle Version.

  • DynamoDB (ohne globale Tabellen) ist ein regionaler Service, was bedeutet, dass er hochgradig verfügbar und intrinsisch widerstandsfähig gegenüber Infrastrukturausfällen, einschließlich des Ausfalls einer gesamten Availability Zone. Eine DynamoDB-Tabelle für eine einzelne Region ist für eine Verfügbarkeit von 99,99 % konzipiert. Weitere Informationen finden Sie unter DynamoDB – Service Level Agreement (SLA).

  • Eine globale DynamoDB-Tabelle repliziert ihre Daten zwischen zwei oder mehr Regionen. Eine DynamoDB-Tabelle für mehrere Regionen ist für eine Verfügbarkeit von 99,999 % konzipiert. Bei richtiger Planung kann mithilfe von globalen Tabellen eine Architektur geschaffen werden, die regionalen Ausfällen standhält.

  • In DynamoDB gibt es keinen globalen Endpunkt. Alle Anforderungen werden an einen regionalen Endpunkt gestellt, der auf die für diese Region lokale Instance der globalen Tabelle zugreift.

  • Aufrufe an DynamoDB sollten nicht regionsübergreifend erfolgen. Als bewährte Methode sollte eine Anwendung, die sich in einer Region befindet, nur auf den lokalen DynamoDB-Endpunkt für diese Region direkt zugreifen. Wenn innerhalb einer Region (auf der DynamoDB-Ebene oder im umgebenden Stack) Probleme festgestellt werden, sollte der Endbenutzer-Datenverkehr an einen anderen Anwendungsendpunkt weitergeleitet werden, der in einer anderen Region gehostet wird. Globale Tabellen stellen sicher, dass Anwendung in jeder Region Zugriff auf dieselben Daten hat.

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), der im Juni 2025 eingeführt wurde.

Wenn Sie beim Erstellen einer globalen Tabelle keinen Konsistenzmodus angeben, wird für die globale Tabelle standardmäßig MREC 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.

Wichtige Fakten zu MREC

  • Globale Tabellen, die MRSC verwenden, nutzen auch ein Aktiv-Aktiv-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 teilnehmende Remote-Regionen.

  • Elemente werden einzeln repliziert. Elemente, die im Rahmen einer einzelnen Transaktion aktualisiert wurden, können möglicherweise nicht zusammen repliziert werden.

  • Jede Tabellenpartition in der Quellregion repliziert ihre Schreibvorgänge parallel zu allen anderen Partitionen. Die Reihenfolge der Schreibvorgänge innerhalb einer Remote-Region entspricht möglicherweise nicht der Reihenfolge der Schreibvorgänge in der Quellregion. 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 Metrik ReplicationLatency bereit. Zur Berechnung dieser Metrik wird die Ankunftszeit eingehender Elemente mit der Zeit verglichen, zu der sie ursprünglich geschrieben wurden, und ein Durchschnitt ermittelt. Die Zeiten werden in CloudWatch in der Quellregion gespeichert. Der Vergleich der durchschnittlichen und maximalen Zeiten kann hilfreich sein, um die durchschnittliche und die stärkste Replikationsverzögerung zu ermitteln. Für diese Latenz gibt es kein SLA.

  • Wenn ein einzelnes Element ungefähr zu derselben Zeit (innerhalb dieses ReplicationLatency-Fensters) in zwei verschiedenen Regionen aktualisiert wird und der zweite Schreibvorgang vor der Replikation des ersten Schreibvorgangs stattfindet, kann es zu Schreibkonflikten kommen. Globale Tabellen, die MREC verwenden, lösen solche Konflikte nach dem Prinzip „Wer zuletzt schreibt, gewinnt“, basierend auf dem Zeitstempel der Schreibvorgänge. Der erste Vorgang „verliert“ gegen den zweiten Vorgang. Diese Konflikte werden nicht in CloudWatch oder AWS CloudTrail aufgezeichnet.

  • Jedes Element verfügt über einen Zeitstempel für den letzten Schreibvorgang, der als private Systemeigenschaft gespeichert wird. Zur Umsetzung des Prinzips „Wer zuletzt schreibt, gewinnt“ wird ein bedingter Schreibvorgang verwendet, der voraussetzt, dass der Zeitstempel des eingehenden Elements größer als der Zeitstempel des vorhandenen Elements ist.

  • In einer globalen Tabelle werden alle Elemente in alle teilnehmenden Regionen repliziert. Wenn Sie unterschiedliche Replikationsbereiche haben möchten, können Sie mehrere globale Tabellen erstellen und jeder Tabelle verschiedene teilnehmende Regionen zuweisen.

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

  • Sollte eine Region vollständig offline gehen, was sehr unwahrscheinlich ist, werden alle ausstehenden ausgehenden und eingehenden Replikationen erneut versucht, wenn sie später wieder online ist. Es sind keine besonderen Maßnahmen erforderlich, um die Tabellen wieder zu synchronisieren. Das Prinzip Wer zuletzt schreibt, gewinnt, stellt sicher, dass die Daten letztendlich konsistent werden.

  • Sie können einer DynamoDB-MREC-Tabelle jederzeit eine neue Region hinzufügen. DynamoDB kümmert sich um die erste Synchronisierung und die fortlaufende Replikation. Sie können eine Region (selbst die ursprüngliche Region) auch entfernen. Dadurch wird die lokale Tabelle in dieser Region gelöscht.

Wichtige Fakten zu MRSC

  • Globale Tabellen, die MRSC verwenden, nutzen auch ein Aktiv-Aktiv-Replikationsmodell. Aus Sicht von DynamoDB ist die Tabelle in jeder Region gleichberechtigt, Lese- und Schreibanforderungen anzunehmen. Elementänderungen im Replikat einer globalen MRSC-Tabelle werden synchron in mindestens eine andere Region repliziert, bevor der Schreibvorgang eine erfolgreiche Antwort zurückgibt.

  • 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. Aktualisierungen beziehen sich immer auf die neueste Version eines Elements.

  • Letztendlich konsistente Lesevorgänge für ein MRSC-Replikat schließen möglicherweise keine Änderungen ein, die kürzlich in einer anderen Region vorgenommen wurden, und möglicherweise nicht einmal Änderungen, die erst vor ganz Kurzem in derselben Region durchgeführt wurden.

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

  • Mit MRSC sind die Latenzen bei Schreibvorgängen und bei strikt konsistenten Lesevorgängen höher. Diese Vorgänge erfordern eine regionsübergreifende Kommunikation. Diese Kommunikation mehr Latenz mit sich bringen, die sich je nach der Round-Trip-Latenz zwischen der Region, auf die zugegriffen wird, und der nächstgelegenen Region, die in der globalen Tabelle aufgeführt ist, erhöht. Weitere Informationen finden Sie in der AWS re:Invent 2024-Präsentation Multi-Region strong consistency with DynamoDB global tables. Bei letztendlich konsistenten Lesevorgängen gibt es keine zusätzliche Latenz. Sie können diese Latenzen in Ihren Regionen mit einem Open-Source-Testtool berechnen.

  • Elemente werden einzeln repliziert. Globale Tabellen, die MRSC verwenden, bieten keine Unterstützung für Transaktions-APIs.

  • Eine globale MRSC-Tabelle muss in genau drei Regionen bereitgestellt werden. 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 aktuelle Daten enthält, die in Replikate der globalen Tabelle geschrieben wurden. Ein Witness bietet eine optionale Alternative zu einem vollständigen Replikat und unterstützt gleichzeitig die Verfügbarkeitsarchitektur von MRSC. Sie können für einen Witness keine Lese- oder Schreibvorgänge ausführen. Für einen Witness fallen keine Speicher- oder Schreibkosten an. Ein Witness befindet sich in einer anderen Region als die beiden Replikate.

  • 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. Im zweiten Szenario wird das verbleibende Replikat in eine DynamoDB-Tabelle mit einer einzelnen Region konvertiert.

  • 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 wird nicht in im AWS-Konto der Region angezeigt, in der er konfiguriert wurde.

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

    • Region-Set USA: USA Ost (Nord-Virginia), USA Ost (Ohio), USA West (Oregon)

    • Region-Set Europa: Europa (Frankfurt), Europa (Irland), Europa (London), Europa (Paris)

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

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

  • Die Funktion „Time to Live“ (TTL) wird von globalen MRSC-Tabellen nicht unterstützt.

  • Lokale sekundäre Indizes (LSIs) werden von globalen MRSC-Tabellen nicht unterstützt.

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

  • Die lokale Region akzeptiert alle Lese- und Schreibvorgänge, solange es eine zweite Region gibt, in der ein Replikat oder ein Witness gehostet wird, um das Quorum einzurichten. Wenn keine zweite Region verfügbar ist, kann die lokale Region nur letztendlich konsistente Lesevorgänge verarbeiten.

  • Im unwahrscheinlichen Fall, dass eine Region vollständig offline geht, holt sie automatisch auf, wenn sie später wieder online ist. Schreibvorgänge und strikt konsistente Lesevorgänge geben Fehler zurück, bis das Aufholen abgeschlossen ist. Bei letztendlich konsistenten Lesevorgängen werden jedoch die Daten zurückgegeben, die bisher in die Region übertragen wurden, wobei das übliche lokale Konsistenzverhalten zwischen dem Führungsknoten und den lokalen Replikaten gilt. Es sind keine besonderen Maßnahmen erforderlich, um die Tabellen wieder zu synchronisieren.

Anwendungsfälle für globale MREC-Tabellen in DynamoDB

Globale MREC-Tabellen bieten folgende Vorteile:

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

  • Schreibvorgänge mit niedrigerer Latenz. Sie können in eine nahegelegene Region schreiben, um die Netzwerklatenz und die für den Schreibvorgang benötigte Zeit zu reduzieren. Der Schreibverkehr muss sorgfältig weitergeleitet werden, um Konflikte zu vermeiden. Die Methoden für die Weiterleitung werden unter Routing-Strategien in DynamoDB ausführlicher erörtert.

  • Nahtlose Migration von Regionen. Sie können eine neue Region hinzufügen und die alte Region löschen, um eine Bereitstellung ohne Ausfallzeit auf der Datenebene von einer Region zu einer anderen zu migrieren.

Die globalen MREC- und MRSC-Tabellen bieten beide den folgenden Vorteil:

  • Verbesserte Resilienz und Notfallwiederherstellung. Wenn es in einer Region zu Leistungseinbußen oder einem vollständigen Ausfall kommt, können Sie diese evakuieren. Evakuieren bedeutet, einige oder alle Anforderungen, die in dieser Region eingehen, zu verschieben. Durch die Verwendung von globalen Tabellen erhöht sich das DynamoDB-SLA für den monatlichen Prozentsatz der Betriebszeit von 99,99 % auf 99,999 %. Die Verwendung von MREC unterstützt einen Recovery Point Objective (RPO) und einen Recovery Time Objective (RTO), die in Sekunden gemessen werden. Bei Verwendung von MRSC wird ein RPO von Null unterstützt.

    Zum Beispiel präsentierte Fidelity Investments auf der re:Invent 2022, wie das Unternehmen globale DynamoDB-Tabellen für sein Auftragsverwaltungssystem verwendet. Ziel war es, eine zuverlässige Verarbeitung mit geringer Latenz in einem Umfang zu erzielen, der mit einer On-Premises-Verarbeitung nicht möglich wäre, dabei aber gleichzeitig die Resilienz gegenüber Ausfällen der Availability Zone und Regionen aufrechtzuerhalten.

Wenn Ihr Ziel Resilienz und Notfallwiederherstellung ist, weisen MRSC-Tabellen zwar höhere Latenzen bei Schreibvorgängen und strikt konsistenten Lesevorgängen auf, unterstützen aber einen RPO von Null. Globale MREC-Tabellen können einen RPO unterstützen, der der verzögerten Replikation zwischen Replikaten entspricht, die je nach Region in der Regel einige Sekunden beträgt.

Fazit und Ressourcen

Globale DynamoDB-Tabellen haben nur sehr wenige Kontrollen, müssen aber dennoch sorgfältig geprüft werden. Sie müssen Ihren Schreibmodus, Ihr Weiterleitungsmodell und Ihre Evakuierungsprozesse festlegen. Sie müssen Ihre Anwendung in jeder Region instrumentieren und bereit sein, Ihre Weiterleitung anzupassen oder eine Evakuierung durchzuführen, um die globale Integrität zu erhalten. Der Vorteil ist, dass Sie auf diese Weise einen global verteilten Datensatz mit Lese- und Schreibvorgängen mit niedriger Latenz erhalten, der auf eine Verfügbarkeit von 99,999 % ausgelegt ist.

Weitere Informationen zu globalen DynamoDB-Tabellen finden Sie in den folgenden Ressourcen: