Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
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 die Version 2019.11.21 (Current) von Global Tables verwenden, da sie mehr Flexibilität und Effizienz bietet und weniger Schreibkapazität verbraucht als 2017.11.29 (Legacy).
Informationen dazu, welche Version Sie verwenden, finden Sie unter Ermitteln der Version der DynamoDB-Tabelle, die Sie verwenden. 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 einem einzigen Konto gehören. AWS
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.
-
Erstellen Sie eine normale DynamoDB-Tabelle mit aktivierten DynamoDB Streams in einer Region. AWS
-
Wiederholen Sie Schritt 1 für alle anderen Regionen, in denen Sie Ihre Daten replizieren möchten.
-
Definieren Sie eine globale Tabelle in DynamoDB basierend auf den Tabellen, die Sie erstellt haben.
Das AWS Management Console automatisiert diese Aufgaben, sodass Sie schneller und einfacher eine globale Tabelle 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 atomarer Vorgang 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 in das Replikat als eigene isolierte Regionstabelle 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 Sie eine IAM Richtlinie, um Schreibvorgänge in die Tabelle nur in einer Region zuzulassen.
Verwenden Sie eine IAM Richtlinie, um Benutzer nur in eine Region weiterzuleiten und die andere Region im Standby-Modus zu belassen oder abwechselnd ungerade Benutzer in eine Region und sogar Benutzer in 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 es verwenden CloudWatch , um die Metrik ReplicationLatency zu beobachten. 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. ReplicationLatencywird in Millisekunden ausgedrückt und für jedes Paar aus Quellregion und Zielregion 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.
Zeit zum Leben (TTL)
Sie können Time To Live (TTL) verwenden, um einen Attributnamen anzugeben, dessen Wert die Ablaufzeit des Elements angibt. Dieser Wert wird als Zahl in Sekunden seit Beginn der Unix-Epoche angegeben.
Bei der älteren Version von Global Tables werden die TTL Löschungen nicht automatisch auf andere Replikate repliziert. Wenn ein Element mithilfe einer TTL Regel gelöscht wird, wird diese Arbeit ausgeführt, ohne dass Schreibeinheiten verbraucht werden.
Beachten Sie, dass, wenn die Quell- und Zieltabelle über eine sehr geringe bereitgestellte Schreibkapazität verfügen, dies zu einer Drosselung führen kann, da für die TTL Löschvorgänge Schreibkapazität erforderlich ist.
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.
Transaktionsoperationen bieten Garantien ACID (Atomizität, Konsistenz, Isolierung und Haltbarkeit) ONLY innerhalb der Region, in der der Schreibvorgang ursprünglich vorgenommen wurde. Transaktionen in globalen Tabellen werden nicht regionsübergreifend unterstützt.
Wenn Sie beispielsweise über eine globale Tabelle mit Replikaten in den Regionen USA Ost (Ohio) und USA West (Oregon) verfügen und einen TransactWriteItems Vorgang in der Region USA Ost (Ohio) ausführen, können Sie beobachten, wie teilweise abgeschlossene Transaktionen in der Region USA West (Oregon) repliziert werden, während Ä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. Daher DAX wird Ihnen nicht bewusst sein, dass sie veraltete Daten enthält. Der DAX Cache wird nur aktualisiert, wenn der Cache abgelaufen istTTL.
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.
Mit 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 aktuelle Menge der in jeder Region bereitgestellten Schreibkapazität wird innerhalb dieser synchronisierten Auto Scaling-Einstellungen unabhängig voneinander steigen und fallen. 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 eventuell konsistente Lesevorgänge verwendet und Lesevorgänge nur 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 beeinträchtigt wird, kann Ihre Anwendung in eine andere Region umleiten 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.
