Globale Tabellen: Funktionsweise

Wichtig

Diese Dokumentation bezieht sich auf globale Tabellen der Version 2017.11.29 (veraltet), die für neue globale Tabellen vermieden werden sollte. Kunden sollten nach Möglichkeit Global Tables Version 2019.11.21 (aktuell) verwenden, da sie mehr Flexibilität und höhere Effizienz bietet und weniger Schreibkapazität verbraucht als 2017.11.29 (veraltet).

Informationen dazu, welche Version Sie verwenden, finden Sie unter Ermitteln der verwendeten Version der globalen Tabellen. Informationen zur Aktualisierung globaler Tabellen von Version 2017.11.29 (veraltet) auf Version 2019.11.21 (aktuell) finden Sie unter Aktualisieren globaler Tabellen.

In den folgenden Abschnitten erfahren Sie mehr über die Konzepte und das Verhalten globaler Tabellen in Amazon DynamoDB.

Globale Tabellenkonzepte für Version 2017.11.29 (veraltet)

Eine globale Tabelle ist eine Sammlung von einer oder mehreren Replikattabellen, die alle zu einem einzigen AWS-Konto gehören.

Eine Replikattabelle (oder kurz ein Replikat) ist eine einzelne DynamoDB-Tabelle, die als Teil einer globalen Tabelle fungiert. Jedes Replikat speichert die gleichen Datenelemente. Jede bestimmte globale Tabelle kann nur über eine Replikattabelle pro AWS-Region verfügen.

Im Folgenden finden Sie einen konzeptionellen Überblick darüber, wie eine globale Tabelle erstellt wird.

1. Erstellen Sie eine normale DynamoDB-Tabelle mit aktivierter DynamoDB Streams in einer AWSRegion.

2. Wiederholen Sie Schritt 1 für alle anderen Regionen, in denen Sie Ihre Daten replizieren möchten.

3. Definieren Sie eine globale Tabelle in DynamoDB basierend auf den Tabellen, die Sie erstellt haben.

Die AWS Management Console automatisiert diese Aufgaben, sodass Sie eine globale Tabelle schneller und einfacher erstellen können. Weitere Informationen finden Sie unter Erstellen einer globalen Tabelle.

Die resultierende globale DynamoDB-Tabelle besteht aus mehreren Replikattabellen, eine pro Region, die DynamoDB als eine Einheit behandelt. Jedes Replikat hat den gleichen Tabellennamen und das gleiche Primärschlüsselschema. Wenn eine Anwendung Daten in eine Replikattabelle in einer Region schreibt, verteilt DynamoDB den Schreibvorgang automatisch auf die anderen Replikattabellen in den übrigen AWS-Regionen.

Wichtig

Um Ihre Tabellendaten synchron zu halten, erstellen globale Tabellen automatisch die folgenden Attribute für jedes Element:

• aws:rep:deleting

• aws:rep:updatetime

• aws:rep:updateregion

Ändern Sie diese Attribute nicht oder erstellen Sie Attribute mit demselben Namen.

Sie können der globalen Tabelle Replikattabellen hinzufügen, sodass sie in weiteren Regionen verfügbar ist. (Dazu muss die globale Tabelle leer sein. Anders ausgedrückt, in keiner Replikattabelle dürfen Daten enthalten sein.)

Sie können eine Replikattabelle auch aus einer globalen Tabelle entfernen. Wenn Sie dies tun, wird die Tabelle vollständig von der globalen Tabelle getrennt. Diese nun unabhängige Tabelle interagiert nicht mehr mit der globalen Tabelle und es werden keine Daten mehr in die und aus der globalen Tabelle übertragen.

Warnung

Beachten Sie, dass das Entfernen eines Replikats kein unteilbarer Prozess ist. Um ein konsistentes Verhalten und einen bekannten Zustand zu gewährleisten, sollten Sie erwägen, den Schreibdatenverkehr Ihrer Anwendung vorher von dem Replikat wegzuleiten, das entfernt werden soll. Warten Sie nach dem Entfernen, bis alle Endpunkte der Replikatregion das Replikat als getrennt anzeigen, bevor Sie weitere Schreibvorgänge als eigene isolierte Tabelle der Regionen vornehmen.

Allgemeine Aufgaben

Allgemeine Aufgaben für globale Tabellen funktionieren wie folgt.

Sie können die Replikattabelle einer globalen Tabelle genauso löschen wie eine reguläre Tabelle. Dadurch wird die Replikation in diese Region beendet und die in dieser Region gespeicherte Tabellenkopie gelöscht. Sie können die Replikation nicht trennen und Kopien der Tabelle als unabhängige Entitäten existieren lassen.

Anmerkung

Sie können eine Quelltabelle erst 24 Stunden, nachdem sie zum Initiieren einer neuen Region verwendet wurde, löschen. Wenn Sie versuchen, sie zu früh zu löschen, erhalten Sie eine Fehlermeldung.

Konflikte entstehen, wenn Anwendungen dasselbe Element in verschiedenen Regionen fast zum gleichen Zeitpunkt aktualisieren. Zur Sicherstellung der letztendliche Konsistenz verwenden globale DynamoDB-Tabellen bei gleichzeitigen Updates einen Mechanismus, bei dem der letzte Schreibvorgang gültig ist. Alle Replikate verständigen sich auf das neueste Update und nähern sich einem Zustand an, in dem sie alle über identische Daten verfügen.

Anmerkung

Es gibt mehrere Möglichkeiten, Konflikte zu vermeiden, unter anderem:

• Verwenden einer IAM-Richtlinie, um nur Schreibvorgänge in die Tabelle in einer Region zuzulassen

• Verwenden einer IAM-Richtlinie, um Benutzer nur an eine Region weiterzuleiten und die andere als Standby-Region zu belassen, oder abwechselnd ungerade Benutzer an eine Region und gerade Benutzer an eine andere Region weiterzuleiten.

• Vermeiden von nicht idempotenten Updates wie Bookmark = Bookmark + 1 und Bevorzugen statischer Updates wie Bookmark=25

Überwachen globaler Tabellen

Sie können verwenden CloudWatch , um die Metrik zu beobachtenReplicationLatency. Diese Metrik verfolgt die verstrichene Zeit zwischen dem Erscheinen eines aktualisierten Elements im DynamoDB-Stream für 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 Quell- und Zielregionspaar ausgegeben. Dies ist die einzige CloudWatch Metrik, die von Global Tables v2 bereitgestellt wird.

Die Latenzen, die Sie beobachten werden, hängen von der Entfernung zwischen den ausgewählten Regionen sowie von anderen Variablen ab. Latenzen im Bereich von 0,5 bis 2,5 Sekunden für Regionen kommen innerhalb desselben geografischen Gebiets häufig vor.

Time to Live (TTL)

Sie können Time to Live (TTL) verwenden, um einen Attributnamen anzugeben, dessen Wert die Ablaufzeit für das Element angibt. Dieser Wert wird als Zahl in Sekunden seit dem Start der Unix-Epoche angegeben.

Mit der Legacy-Version von globalen Tabellen werden die TTL-Löschungen nicht automatisch auf andere Replikate repliziert. Wenn ein Element über eine TTL-Regel gelöscht wird, wird diese Arbeit ausgeführt, ohne dass Schreibeinheiten verbraucht werden.

Hinweis: Wenn die Quell- und Zieltabellen eine sehr geringe bereitgestellte Schreibkapazität haben, kann dies zu einer Drosselung führen, da die TTL-Löschungen Schreibkapazität erfordern.

Streams und Transaktionen mit globalen Tabellen

Jede globale Tabelle erzeugt einen unabhängigen Stream, der auf all ihren Schreibvorgängen basiert, unabhängig vom Ausgangspunkt dieser Schreibvorgänge. Sie können wählen, ob Sie diesen DynamoDB-Stream in einer Region oder in allen Regionen unabhängig voneinander nutzen möchten.

Wenn Sie verarbeitete lokale Schreibvorgänge, aber keine replizierten Schreibvorgänge möchten, können Sie jedem Element Ihr eigenes Regionsattribut hinzufügen. Dann können Sie einen Lambda-Ereignisfilter verwenden, um nur Lambda für Schreibvorgänge in der lokalen Region aufzurufen.

Transaktionale Operationen umfassen ACID (Atomizität, Konsistenz, Isolierung und Zuverlässigkeit) NUR in der Region, in der der Schreibvorgang ursprünglich durchgeführt wurde. Regionsübergreifende Transaktionen werden in globalen Tabellen nicht unterstützt.

Wenn Sie beispielsweise eine globale Tabelle mit Replikaten in den Regionen USA Ost (Ohio) und USA West (Oregon) haben und eine TransactWriteItems Operation in der Region USA Ost (Ohio) ausführen, können Sie teilweise abgeschlossene Transaktionen in der Region USA West (Oregon) beobachten, wenn Änderungen repliziert werden. Die Änderungen werden erst in die anderen Regionen repliziert, nachdem sie in der Quellregion in die Datenbank eingetragen wurden.

Anmerkung

• Globale Tabellen „umgehen“ DynamoDB Accelerator (DAX), indem sie DynamoDB direkt aktualisieren. Infolgedessen ist DAX nicht bekannt, dass er veraltete Daten speichert. Der DAX-Cache wird erst aktualisiert, wenn die TTL des Caches abläuft.

• Tags in globalen Tabellen werden nicht automatisch weitergegeben.

Lese- und Schreibdurchsatz

Globale Tabellen verwalten den Lese- und Schreibdurchsatz wie folgt.

• Die Schreibkapazität muss auf allen Tabellen-Instances in sämtlichen Regionen gleich sein.

• Bei Version 2019.11.21 (aktuell) wird die Schreibkapazität automatisch synchronisiert, wenn die Tabelle so eingestellt ist, dass sie Auto Scaling unterstützt oder sich im On-Demand-Modus befindet. Die derzeit in jeder Region bereitgestellte Schreibkapazität steigt und fällt innerhalb dieser synchronisierten Auto-Scaling-Einstellungen unabhängig voneinander. Wenn die Tabelle in den On-Demand-Modus versetzt wird, wird dieser Modus mit den anderen Replikaten synchronisiert.

• Die Lesekapazität kann je nach Region unterschiedlich sein, da die Lesevorgänge möglicherweise nicht identisch sind. Beim Hinzufügen eines globalen Replikats zu einer Tabelle wird die Kapazität der Quellregion übertragen. Nach der Erstellung können Sie die Lesekapazität für ein Replikat anpassen und diese neue Einstellung wird nicht auf die andere Seite übertragen.

Konsistenz und Konfliktlösung

Alle Änderungen, die an einem Element in einer Replikattabelle vorgenommen werden, werden auf alle anderen Replikate innerhalb derselben globalen Tabelle repliziert. In einer globalen Tabelle wird ein neu geschriebenes Element in der Regel innerhalb von wenigen Sekunden auf alle Replikattabellen verteilt.

Mit einer globalen Tabelle speichert jede Replikattabelle die gleichen Datenelemente. DynamoDB unterstützt keine Teilreplikation nur einiger Elemente.

Eine Anwendung hat Lese- und Schreibzugriff auf alle Replikattabellen. DynamoDB unterstützt letztendlich konsistente Lesevorgänge regionsübergreifend, jedoch keine strikt konsistenten Lesevorgänge in allen Regionen. Wenn Ihre Anwendung nur Eventually-Consistent-Lesevorgänge verwendet und nur Lesevorgänge für eine AWS-Region ausgibt, funktioniert sie ohne Änderungen. Wenn Ihre Anwendung jedoch strikt konsistente Lesevorgänge erfordert, muss sie alle strikt konsistenten Lese- und Schreibvorgänge in derselben Region ausführen. Wenn Sie in eine Region schreiben und aus einer anderen Region lesen, kann die Leseantwort veraltete Daten enthalten, die nicht die Ergebnisse kürzlich abgeschlossener Schreibvorgänge in der anderen Region widerspiegeln.

Konflikte entstehen, wenn Anwendungen dasselbe Element in verschiedenen Regionen fast zum gleichen Zeitpunkt aktualisieren. Um die letztendliche Konsistenz sicherzustellen, verwenden globale DynamoDB-Tabellen den letzter-Verfasser-gewinnt-Abgleich zwischen gleichzeitigen Updates, bei dem DynamoDB sich nach besten Kräften bemüht, den letzten Verfasser zu ermitteln. Mit diesem Konfliktlösungsmechanismus verständigen sich alle Replikate auf das neueste Update und nähern sich einem Zustand an, in dem sie alle über identische Daten verfügen.

Verfügbarkeit und Beständigkeit

Wenn eine einzelne AWS-Region isoliert oder heruntergestuft wird, kann Ihre Anwendung eine Weiterleitung auf eine andere Region vornehmen und Lese- und Schreibvorgänge für eine andere Replikattabelle ausführen. Sie können benutzerdefinierte Geschäftslogik anwenden, um zu ermitteln, wann Anforderungen an andere Regionen weitergeleitet werden sollen.

Wenn eine Region isoliert oder heruntergestuft wird, verfolgt DynamoDB alle Schreibvorgänge, die zwar durchgeführt, aber noch nicht auf alle Replikattabellen verteilt wurden. Wenn die Region wieder online ist, setzt DynamoDB die Weitergabe aller ausstehenden Schreibvorgänge aus dieser Region an die Replikattabellen in anderen Regionen fort. Außerdem wird das Übertragen von Schreibvorgängen aus anderen Replikattabellen in die Region fortgesetzt, die jetzt wieder online ist. Alle zuvor erfolgreichen Schreibvorgänge werden letztendlich weitergegeben, unabhängig davon, wie lange die Region isoliert ist.