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.

So funktionieren globale DynamoDB-Tabellen

In den folgenden Abschnitten werden die Konzepte und das Verhalten globaler Tabellen in Amazon DynamoDB beschrieben.

Konzepte

Globale Tabellen sind eine DynamoDB-Funktion, die Tabellendaten regionsübergreifend repliziert. AWS

Eine Replikattabelle (oder ein Replikat) ist eine DynamoDB-Tabelle, die als Teil einer globalen Tabelle fungiert. Eine globale Tabelle besteht aus zwei oder mehr Replikattabellen in verschiedenen Regionen. AWS Jede globale Tabelle kann nur ein Replikat pro AWS Region haben. Alle Replikate in einer globalen Tabelle verwenden denselben Tabellennamen, dasselbe Primärschlüsselschema und dieselben Elementdaten.

Wenn eine Anwendung Daten in ein Replikat in einer Region schreibt, repliziert DynamoDB den Schreibvorgang automatisch auf alle anderen Replikate in der globalen Tabelle. Weitere Informationen über die ersten Schritte mit globalen Tabellen finden Sie unter Tutorials: Globale Tabellen erstellen.

Versionen

Es sind zwei Versionen der globalen DynamoDB-Tabellen verfügbar: Version 2019.11.21 (aktuell) und Version 2017.11.29 (Legacy). Sie sollten wann immer möglich Version 2019.11.21 (aktuell) verwenden. Die Informationen in diesem Dokumentationsabschnitt beziehen sich auf Version 2019.11.21 (Aktuell). Weitere Informationen finden Sie unter Ermitteln der Version einer globalen Tabelle.

Verfügbarkeit

Globale Tabellen tragen zur Verbesserung Ihrer Geschäftskontinuität bei, indem sie die Implementierung einer Hochverfügbarkeitsarchitektur für mehrere Regionen erleichtern. Wenn eine Arbeitslast in einer einzelnen AWS Region beeinträchtigt wird, können Sie den Anwendungsdatenverkehr in eine andere Region verlagern und Lese- und Schreibvorgänge in einer anderen Replikattabelle in derselben globalen Tabelle durchführen.

Jede Replikattabelle in einer globalen Tabelle bietet dieselbe Haltbarkeit und Verfügbarkeit wie eine DynamoDB-Tabelle mit einer Region. Globale Tabellen bieten ein Service Level Agreement (SLA) mit einer Verfügbarkeit von 99,999%, verglichen mit 99,99% für Tabellen mit einer einzelnen Region.

Konsistenzmodi

Wenn Sie eine globale Tabelle erstellen, können Sie ihren Konsistenzmodus konfigurieren. Globale Tabellen unterstützen zwei Konsistenzmodi: Multi-Region Eventual Consistency (MREC) und Multi-Region Strong Consistency (MRSC).

Wenn Sie beim Erstellen einer globalen Tabelle keinen Konsistenzmodus angeben, verwendet die globale Tabelle standardmäßig Multi-Region Eventual Consistency (MREC). Eine globale Tabelle kann keine Replikate enthalten, die mit unterschiedlichen Konsistenzmodi konfiguriert wurden. Sie können den Konsistenzmodus einer globalen Tabelle nach der Erstellung nicht ändern.

Eventuelle Konsistenz mehrerer Regionen (MREC)

Multi-Region Eventual Consistency (MREC) ist der Standardkonsistenzmodus für globale Tabellen. Elementänderungen in einem globalen MREC-Tabellenreplikat werden asynchron auf alle anderen Replikate repliziert, normalerweise innerhalb einer Sekunde oder weniger. In dem unwahrscheinlichen Fall, dass ein Replikat in einer globalen MREC-Tabelle isoliert oder beeinträchtigt wird, werden alle Daten, die noch nicht in andere Regionen repliziert wurden, repliziert, sobald das Replikat fehlerfrei ist.

Wenn dasselbe Element in mehreren Regionen gleichzeitig geändert wird, löst DynamoDB den Konflikt, indem es die Änderung mit dem neuesten internen Zeitstempel pro Element verwendet, was als Konfliktlösungsmethode „Last Writer Wins“ bezeichnet wird. Ein Element wird irgendwann in allen Replikaten mit der Version konvergieren, die beim letzten Schreibvorgang erstellt wurde.

Streng konsistente Lesevorgänge geben die neueste Version eines Elements zurück, wenn dieses Element zuletzt in der Region aktualisiert wurde, in der der Lesevorgang stattgefunden hat. Es können jedoch veraltete Daten zurückgegeben werden, wenn das Element zuletzt in einer anderen Region aktualisiert wurde. Bei bedingten Schreibvorgängen wird der Bedingungsausdruck mit der Version des Elements in der Region verglichen.

Sie erstellen eine globale MREC-Tabelle, indem Sie einer vorhandenen DynamoDB-Tabelle ein Replikat hinzufügen. Das Hinzufügen eines Replikats hat keine Auswirkungen auf die Leistung vorhandener DynamoDB-Tabellen mit einer Region oder globaler Tabellenreplikate. Sie können einer globalen MREC-Tabelle Replikate hinzufügen, um die Anzahl der Regionen zu erhöhen, in denen Daten repliziert werden, oder Replikate aus einer globalen MREC-Tabelle entfernen, wenn sie nicht mehr benötigt werden. Eine globale MREC-Tabelle kann ein Replikat in jeder Region haben, in der DynamoDB verfügbar ist, und sie kann so viele Replikate haben, wie Regionen in der Partition vorhanden sind.AWS

Starke Konsistenz in mehreren Regionen (MRSC)

Sie können den MRSC-Modus (Multi-Region Strong Consistency) konfigurieren, wenn Sie eine globale Tabelle erstellen. Elementänderungen in einem globalen MRSC-Tabellenreplikat werden synchron in mindestens eine andere Region repliziert, bevor der Schreibvorgang eine erfolgreiche Antwort zurückgibt. Wenn Sie eine bestehende Tabelle mit einer einzigen Region in eine globale MRSC-Tabelle konvertieren, müssen Sie sicherstellen, dass die Tabelle leer ist, bis die Konvertierung abgeschlossen ist, um eine korrekte Initialisierung und Replikationseinrichtung sicherzustellen.

Stark konsistente Lesevorgänge für ein beliebiges MRSC-Replikat geben immer die neueste Version eines Elements zurück. Bei bedingten Schreibvorgängen wird der Bedingungsausdruck immer anhand der neuesten Version eines Elements ausgewertet.

Ein Schreibvorgang schlägt mit a fehlReplicatedWriteConflictException, wenn versucht wird, ein Element zu ändern, das bereits in einer anderen Region geändert wird. Schreibvorgänge, die mit dem fehlschlagen, ReplicatedWriteConflictException können wiederholt werden und sind erfolgreich, wenn das Element in einer anderen Region nicht mehr geändert wird.

Sie können eine globale MRSC-Tabelle mit drei Replikaten oder mit zwei Replikaten und einem Zeugen konfigurieren. Ein Zeuge ist eine Komponente einer globalen MRSC-Tabelle, die Daten enthält, die in globale Tabellenreplikate geschrieben wurden. Er bietet eine optionale Alternative zu einem vollständigen Replikat und unterstützt gleichzeitig die Verfügbarkeitsarchitektur von MRSC. Sie können für einen Zeugen keine Lese- oder Schreibvorgänge ausführen. Ein Zeuge befindet sich in einer anderen Region als die beiden Replikate.

Wenn Sie eine globale MRSC-Tabelle erstellen, wählen Sie bei der Erstellung der MRSC-Tabelle die Regionen sowohl für Ihre Replikate als auch für die Zeugenbereitstellung aus. Sie können anhand der Ausgabe der API bestimmen, ob und in welcher Region für eine globale MRSC-Tabelle ein Zeuge konfiguriert ist. DescribeTable Der Zeuge gehört DynamoDB und wird von DynamoDB verwaltet, und der Zeuge wird nicht in Ihrem AWS Konto in der Region angezeigt, in der er konfiguriert ist.

Eine globale MRSC-Tabelle muss in genau drei Regionen bereitgestellt werden. Sie erstellen eine globale MRSC-Tabelle, indem Sie einer vorhandenen DynamoDB-Tabelle, die keine Daten enthält, ein Replikat und einen Zeugen oder zwei Replikate hinzufügen. Sie können einer vorhandenen globalen MRSC-Tabelle keine zusätzlichen Replikate hinzufügen. Sie können kein einzelnes Replikat oder einen Zeugen aus einer globalen MRSC-Tabelle löschen. Sie können zwei Replikate oder ein Replikat und einen Zeugen aus einer globalen MRSC-Tabelle löschen und das verbleibende Replikat in eine DynamoDB-Tabelle mit einer einzigen Region konvertieren.

Die folgenden Überlegungen gelten für globale MRSC-Tabellen:

Wählen Sie einen Konsistenzmodus

Das Hauptkriterium für die Auswahl eines Konsistenzmodus für mehrere Regionen ist, ob Ihre Anwendung Schreibvorgänge mit niedrigerer Latenz und stark konsistente Lesevorgänge oder globale, starke Konsistenz priorisiert.

Globale MREC-Tabellen weisen im Vergleich zu globalen MRSC-Tabellen geringere Schreib- und stark konsistente Leselatenzen auf. Globale MREC-Tabellen können ein Recovery Point Objective (RPO) unterstützen, das der Replikationsverzögerung zwischen Replikaten entspricht, die je nach Replikatregion in der Regel einige Sekunden beträgt.

Sie sollten den MREC-Modus verwenden, wenn:

Globale MRSC-Tabellen weisen im Vergleich zu globalen MREC-Tabellen höhere Schreib- und stark konsistente Leselatenzen auf. Globale MRSC-Tabellen unterstützen ein Recovery Point Objective (RPO) von Null.

Sie sollten den MRSC-Modus verwenden, wenn:

Überwachen globaler Tabellen

In globalen Tabellen, die für Multi-Region Eventual Consistency (MREC) konfiguriert sind, wird die Metrik veröffentlicht. ReplicationLatency CloudWatch Diese Metrik verfolgt die verstrichene Zeit zwischen dem Schreiben eines Elements in eine Replikattabelle und dem Erscheinen dieses Elements in einem anderen Replikat in der globalen Tabelle. ReplicationLatencywird in Millisekunden ausgedrückt und für jedes Quell- und Zielregionspaar in einer globalen Tabelle ausgegeben.

Typische ReplicationLatency Werte hängen von der Entfernung zwischen den ausgewählten AWS Regionen sowie von anderen Variablen wie Workload-Typ und Durchsatz ab. Beispiel: Ein Quellreplikat in der Region USA West (Nordkalifornien) (us-west-1) weist im Vergleich ReplicationLatency zur Region Afrika (Kapstadt) (af-south-1) einen niedrigeren Wert auf die Region USA West (Oregon) (us-west-2) auf.

Ein steigender Wert für ReplicationLatency könnte darauf hinweisen, dass Aktualisierungen von einem Replikat nicht rechtzeitig an andere Replikattabellen weitergegeben werden. In diesem Fall können Sie die Lese- und Schreibaktivitäten Ihrer Anwendung vorübergehend in eine andere Region umleiten. AWS

Globale Tabellen, die für MRSC (Multi-Region Strong Consistency) konfiguriert sind, veröffentlichen keine Metrik. ReplicationLatency

Testen von Fehlerinjektionen

Die globalen MREC-Tabellen lassen sich in den AWS Fault Injection Service (AWS FIS) integrieren, um Fault-Injection-Experimente an Ihren globalen Tabellen-Workloads durchzuführen. Auf diese Weise können Sie die Reaktion Ihrer Anwendung auf eine simulierte Regionsisolierung testen, indem Sie die Replikation zu und von einem ausgewählten Replikat unterbrechen. Weitere Informationen finden Sie unter Unterbrechen der globalen Tabellenreplikation.

Time to Live (TTL)

Für MREC konfigurierte globale Tabellen unterstützen die Konfiguration des TTL-Löschvorgangs (Time To Live). TTL-Einstellungen werden automatisch für alle Replikate in einer globalen Tabelle synchronisiert. Wenn TTL ein Element aus einem Replikat in einer Region löscht, wird der Löschvorgang auf alle anderen Replikate in der globalen Tabelle repliziert. TTL verbraucht keine Schreibkapazität, sodass Ihnen das TTL-Löschen in der Region, in der das Löschen stattgefunden hat, nicht in Rechnung gestellt wird. In jeder anderen Region mit einem Replikat in der globalen Tabelle wird Ihnen jedoch der replizierte Löschvorgang in Rechnung gestellt.

Die TTL-Löschreplikation verbraucht Schreibkapazität auf den Replikaten, auf die der Löschvorgang repliziert wird. Replikate, die für bereitgestellte Kapazität konfiguriert sind, können Anfragen drosseln, wenn die Kombination aus Schreibdurchsatz und TTL-Löschdurchsatz höher ist als die bereitgestellte Schreibkapazität.

Globale Tabellen, die für MRSC (Multi-Region Strong Consistency) konfiguriert sind, unterstützen die Konfiguration des TTL-Löschvorgangs (Time To Live) nicht.

Streams

Globale Tabellen, die für Multi-Region Eventual Consistency (MREC) konfiguriert sind, replizieren Änderungen, indem sie diese Änderungen aus einem DynamoDB-Stream in einer Replikattabelle lesen und diese Änderung auf alle anderen Replikattabellen anwenden. Streams sind daher standardmäßig für alle Replikate in einer globalen MREC-Tabelle aktiviert und können auf diesen Replikaten nicht deaktiviert werden. Der MREC-Replikationsprozess kann mehrere Änderungen in einem kurzen Zeitraum zu einem einzigen replizierten Schreibvorgang kombinieren, was dazu führt, dass der Stream jedes Replikats leicht unterschiedliche Datensätze enthält. Streams-Datensätze auf MREC-Replikaten werden immer pro Element sortiert, aber die Reihenfolge zwischen den Elementen kann sich von Replikat zu Replikat unterscheiden.

Globale Tabellen, die für Multi-Region Strong Consistency (MRSC) konfiguriert sind, verwenden keine DynamoDB Streams für die Replikation, sodass Streams auf MRSC-Replikaten standardmäßig nicht aktiviert sind. Sie können Streams auf einem MRSC-Replikat aktivieren. Streams-Datensätze auf MRSC-Replikaten sind für jedes Replikat identisch, einschließlich der Reihenfolge der Stream-Datensätze.

Wenn Sie eine Anwendung schreiben möchten, die Streams-Datensätze für Änderungen verarbeitet, die in einer bestimmten Region, aber nicht in anderen Regionen in einer globalen Tabelle vorgenommen wurden, können Sie jedem Element ein Attribut hinzufügen, das definiert, in welcher Region die Änderung für dieses Element stattgefunden hat. Sie können dieses Attribut verwenden, um Streams-Datensätze nach Änderungen zu filtern, die in anderen Regionen aufgetreten sind, einschließlich der Verwendung von Lambda-Ereignisfiltern, um Lambda-Funktionen nur für Änderungen in einer bestimmten Region aufzurufen.

Transaktionen

In einer für MREC konfigurierten globalen Tabelle sind DynamoDB-Transaktionsoperationen (TransactWriteItemsund TransactGetItems) nur innerhalb der Region, in der der Vorgang aufgerufen wurde, atomar. Transaktionale Schreibvorgänge werden nicht als Einheit regionsübergreifend repliziert, was bedeutet, dass nur einige der Schreibvorgänge in einer Transaktion zu einem bestimmten Zeitpunkt durch Lesevorgänge in anderen Replikaten zurückgegeben werden können.

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.

Globale Tabellen, die für Multi-Region Strong Consistency (MRSC) konfiguriert sind, unterstützen keine Transaktionsvorgänge und geben einen Fehler zurück, wenn diese Operationen auf einem MRSC-Replikat aufgerufen werden.

Lese- und Schreibdurchsatz

Die Replikation verbraucht Schreibkapazität. Replikate, die für bereitgestellte Kapazität konfiguriert sind, können Anfragen drosseln, wenn die Kombination aus Schreibdurchsatz und Replikationsdurchsatz höher ist als die bereitgestellte Schreibkapazität. Die Schreibkapazität im On-Demand-Modus wird für alle Replikate in einer globalen Tabelle synchronisiert. Globale Tabellen, die für bereitgestellte Kapazität konfiguriert sind, synchronisieren Auto-Scaling-Einstellungen zwischen Replikaten. Die tatsächlich bereitgestellte Schreibkapazitätseinstellung kann je nach verbrauchtem Schreibdurchsatz von Replikat zu Replikat variieren.

Sie können die Lesekapazitätseinstellungen für jedes Replikat in einer globalen Tabelle unabhängig konfigurieren. Beim Hinzufügen eines Replikats zu einer globalen Tabelle wird die Lesekapazität der Quelltabelle oder des Replikats als Anfangswert verwendet, sofern kein Override-Wert angegeben ist.

Synchronisation der Einstellungen

Einstellungen in globalen DynamoDB-Tabellen sind Konfigurationsparameter, die verschiedene Aspekte des Tabellenverhaltens und der Replikation steuern. Diese Einstellungen werden über die DynamoDB-Steuerebene verwaltet APIs und können beim Erstellen oder Ändern globaler Tabellen konfiguriert werden. Globale Tabellen synchronisieren automatisch bestimmte Einstellungen für alle Replikate, um die Konsistenz zu wahren und gleichzeitig Flexibilität für regionsspezifische Optimierungen zu ermöglichen. Wenn Sie wissen, welche Einstellungen synchronisiert werden und wie sie sich verhalten, können Sie Ihre globale Tabelle effektiv konfigurieren. Je nachdem, wie sie replikatsübergreifend synchronisiert werden, lassen sich die Einstellungen in drei Hauptkategorien einteilen.

Die folgenden Einstellungen werden immer zwischen Replikaten in einer globalen Tabelle synchronisiert:

Die folgenden Einstellungen werden zwischen Replikaten synchronisiert, können jedoch pro Replikat außer Kraft gesetzt werden:

Die folgenden Einstellungen werden niemals zwischen Replikaten synchronisiert:

Alle anderen Einstellungen werden nicht zwischen Replikaten synchronisiert.

DynamoDB Accelerator (DAX).

Schreibvorgänge in globale Tabellenreplikate umgehen DynamoDB Accelerator (DAX) und aktualisieren DynamoDB direkt. Dadurch können DAX-Caches veraltet werden, da Schreibvorgänge den DAX-Cache nicht aktualisieren. DAX-Caches, die für globale Tabellenreplikate konfiguriert sind, werden nur aktualisiert, wenn die Cache-TTL abläuft.

Überlegungen zur Verwaltung globaler Tabellen

Sie können eine Tabelle, die zum Hinzufügen eines neuen globalen Tabellenreplikats verwendet wurde, erst löschen, wenn seit der Erstellung des neuen Replikats 24 Stunden vergangen sind.

Wenn Sie eine AWS Region deaktivieren, die globale Tabellenreplikate enthält, werden diese Replikate 20 Stunden, nachdem die Region deaktiviert wurde, dauerhaft in Tabellen mit einer einzigen Region konvertiert.