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.
In den folgenden Abschnitten werden die Konzepte und das Verhalten globaler Tabellen in Amazon DynamoDB beschrieben.
Globale Tabellen – Konzepte
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. Weitere Informationen über die ersten Schritte mit globalen Tabellen finden Sie unter Tutorial: Erstellen einer globalen Tabelle.
Wenn Sie eine globale DynamoDB-Tabelle erstellen, besteht diese aus mehreren Replikattabellen (eine für jede Region), die von DynamoDB als eine Einheit behandelt werden. Jedes Replikat hat den gleichen Tabellennamen und das gleiche Primärschlüsselschema. Wenn eine Anwendung Daten in eine Replikattabelle in einer Region schreibt, leitet DynamoDB den Schreibvorgang automatisch an die anderen Replikattabellen in den anderen Regionen weiter. AWS
Sie können der globalen Tabelle Replikattabellen hinzufügen, sodass sie in weiteren Regionen verfügbar ist.
Wenn Sie mit Version 2019.11.21 (aktuell) einen globalen sekundären Index in einer Region erstellen, wird dieser automatisch in die andere(n) Region(en) repliziert und automatisch per Backfill mit neuen Werten gefüllt.
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 unterbrechen und dafür sorgen, dass Kopien der Tabelle als unabhängige Entitäten existieren. Sie können die globale Tabelle in eine lokale Tabelle in dieser Region kopieren und dann das globale Replikat für diese Region löschen.
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:
Zulassen nur von Schreibvorgängen in die Tabelle in einer Region
Weiterleiten des Benutzerverkehrs in verschiedene Regionen gemäß Ihren Schreibrichtlinien, um sicherzustellen, dass es keine Konflikte gibt
Vermeiden von nicht idempotenten Updates wie Bookmark = Bookmark + 1 und Bevorzugen statischer Updates wie Bookmark=25
Beachten Sie, dass es bei der Weiterleitung von Schreib- oder Lesevorgängen in eine Region Sache Ihrer Anwendung ist, sicherzustellen, dass der Datenfluss durchgesetzt wird.
Überwachen globaler Tabellen
Sie können es verwenden CloudWatch , um die Metrik ReplicationLatency zu beobachten. Auf diese Weise wird die verstrichene Zeit zwischen dem Schreiben eines Elements in eine Replikattabelle und dem Erscheinen dieses Elements in einem anderen Replikat der globalen Tabelle verfolgt. Sie wird in Millisekunden angegeben und für jedes Quell- und Ziel-Regionspaar ausgegeben. Diese Metrik wird in der Quellregion gespeichert. Dies ist die einzige CloudWatch Metrik, die von Global Tables v2 bereitgestellt wird.
Die Latenz bei der Replikation hängt von der Entfernung zwischen den von Ihnen ausgewählten AWS-Regionen Geräten sowie von anderen Variablen ab. Wenn sich Ihre Originaltabelle in der Region USA West (Nordkalifornien) (us-west-1) befand, hätte ein Replikat in einer näheren Region, wie der Region USA West (Oregon) (us-west-2), eine geringere Replikationslatenz als ein Replikat in einer viel weiter entfernten Region, wie der Region Afrika (Kapstadt) (af-south-1).
Anmerkung
Die Replikationslatenz hat keinen Einfluss auf die API-Latenz. Wenn Sie einen Client und eine Tabelle in Region A haben und ein globales Tabellenreplikat in Region B hinzufügen, haben der Client und die Tabelle in Region A dieselbe Latenz wie vor dem Hinzufügen von Region B. Wenn Sie den PutItemAPI-Vorgang in Region B aufrufen, kann er irgendwann in Region A gelesen werden, und zwar mit einer Verzögerung, die ungefähr der in Amazon verfügbaren ReplicationLatency Statistik entspricht. CloudWatch Bevor es repliziert wird, erhalten Sie eine leere Antwort und nach der Replikation erhalten Sie das Element. Beide Aufrufe hätten ungefähr die gleiche API-Latenz.
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 Beginn der Unix-Epoche angegeben. Nach Ablauf dieser Zeit kann DynamoDB das Element löschen, ohne dass Schreibkosten anfallen.
Bei globalen Tabellen konfigurieren Sie TTL in einer Region und diese Einstellung wird automatisch auf die andere(n) Region(en) repliziert. Wenn ein Element mithilfe einer TTL-Regel gelöscht wird, wird diese Aufgabe ausgeführt, ohne dass Schreibeinheiten für die Quelltabelle verbraucht werden. Für die Zieltabelle(n) fallen jedoch die Kosten für replizierte Schreibeinheiten an.
Beachten Sie, dass, wenn die Quell- und Zieltabellen über sehr geringe bereitgestellte Schreibkapazitäten verfügen, dies zu einer Drosselung führen kann, da für TTL-Löschungen 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 lokale Schreibvorgänge, aber keine replizierten Schreibvorgänge verarbeiten möchten, können Sie jedem Element Ihr eigenes Region-Attribut hinzufügen. Dann können Sie einen Lambda-Ereignisfilter verwenden, um nur Lambda für Schreibvorgänge in der lokalen Region aufzurufen.
Transaktionsoperationen bieten ACID-Garantien (Atomicity, Consistency, Isolation, Durability) nur 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. Änderungen werden erst dann in andere Regionen repliziert, wenn sie in der Quellregion übernommen wurden.
Anmerkung
Globale Tabellen „umgehen“ DynamoDB Accelerator (DAX), indem sie DynamoDB direkt aktualisieren. Aus diesem Grund wird DAX nicht wissen, dass es veraltete Daten enthält. 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.
In 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. Das bedeutet, dass eine Änderung der Schreibkapazität in einer Tabelle auf die anderen repliziert wird.
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 an einem Element einer Replikattabelle 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 Sätze von Datenelementen. DynamoDB unterstützt keine Teilreplikation nur einiger Elemente.
Eine Anwendung hat Lese- und Schreibzugriff auf alle Replikattabellen. 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 Strongly-Consistent-Lesevorgänge erfordert, muss sie alle Strongly-Consistent-Lese- und Schreibvorgänge in derselben Region ausführen. DynamoDB unterstützt keine stark konsistenten Lesevorgänge in allen Regionen. Wenn Sie also 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 einen letzten Verfasser gewinnt-Abgleich zwischen gleichzeitigen Updates, bei dem DynamoDB sich nach besten Kräften bemüht, den letzten Verfasser zu ermitteln. Dies erfolgt auf Elementebene. 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 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 herabgestuft wird, verfolgt DynamoDB alle Schreibvorgänge, die ausgeführt, aber nicht an alle Replikattabellen weitergegeben 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 nimmt sie die Weitergabe von Schreibvorgängen aus anderen Replikattabellen in die Region wieder auf, die jetzt wieder online ist.
