Ü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.

• Globale Tabellen verwenden 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 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 lösen solche Konflikte mithilfe eines Last-Writer-Wins-Mechanismus, der auf dem Zeitstempel der Schreibvorgänge basiert. Die erste Operation „verliert“ gegenüber der zweiten 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-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.

• 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.

Anwendungsfälle

Globale Tabellen bieten die folgenden allgemeinen 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.

• Verbesserte Resilienz und Notfallwiederherstellung. Wenn in einer Region Leistungseinbußen oder ein vollständiger Ausfall zu verzeichnen ist, können Sie sie evakuieren (einige oder alle Anfragen, die in diese Region gehen, verschieben) und dabei ein in Sekunden gemessenes Recovery Point Objective (RPO) und Recovery Time Objective (RTO) einhalten. Durch die Verwendung globaler Tabellen wird auch der DynamoDB-SLA für die monatliche Verfügbarkeit in Prozent von 99,99% auf 99,999% erhöht.

• 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.

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.