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.
Modus „Schreiben in eine Region“ (einzelne Primärregion)
Der Schreibmodus „In eine Region schreiben“, wie in der folgenden Abbildung dargestellt, ist aktiv/passiv und leitet alle Schreibvorgänge für Tabellen an eine einzige aktive Region weiter. (DynamoDB hat keine Vorstellung von einer einzelnen aktiven Region; die Ebene außerhalb von DynamoDB verwaltet dies.) Der Modus „In eine Region schreiben“ eignet sich gut für MREC-Tabellen, bei denen Schreibkonflikte vermieden werden müssen, indem sichergestellt wird, dass Schreibvorgänge jeweils nur in einer Region ausgeführt werden. Dieser Schreibmodus ist hilfreich, wenn Sie bedingte Ausdrücke verwenden möchten und MRSC aus irgendeinem Grund nicht verwenden können oder wenn Sie Transaktionen ausführen müssen. Diese Ausdrücke sind nur möglich, wenn Sie wissen, dass Sie gegen die neuesten Daten vorgehen. Sie erfordern daher, dass alle Schreibanforderungen an eine einzelne Region gesendet werden, die die neuesten Daten enthält.
Wenn Sie eine MRSC-Tabelle verwenden, können Sie der Einfachheit halber generell in eine Region schreiben. Dies kann beispielsweise dazu beitragen, den Ausbau Ihrer Infrastruktur über DynamoDB hinaus zu minimieren. Der Schreibmodus wäre immer noch das Schreiben in eine beliebige Region, da Sie mit MRSC jederzeit sicher in jede Region schreiben könnten, ohne sich Gedanken über die Konfliktlösung machen zu müssen, die dazu führen würde, dass MREC-Tabellen entscheiden würden, in eine Region zu schreiben.
Schließlich können konsistente Lesevorgänge in jede der Replikatregionen übertragen werden, um geringere Latenzen zu erreichen. Stark konsistente Lesevorgänge müssen sich auf die einzelne primäre Region beziehen.
Manchmal ist es notwendig, die aktive Region als Reaktion auf einen regionalen Fehler zu ändern, wie später beschrieben wird. Einige Benutzer ändern die derzeit aktive Region regelmäßig, z. B. bei der Implementierung einer follow-the-sunBereitstellung. Dadurch wird die aktive Region in der Nähe der Region mit der höchsten Aktivität platziert (normalerweise dort, wo es Tag ist, daher der Name), was zu Lese- und Schreibvorgängen mit der niedrigsten Latenz führt. Es hat auch den Nebeneffekt, dass der Code, der die Region ändert, täglich aufgerufen wird und sichergestellt wird, dass er vor einer Notfallwiederherstellung gründlich getestet wurde.
Die passive (n) Region (en) kann DynamoDB mit einer herunterskalierten Infrastruktur umgeben, die nur aufgebaut wird, wenn sie zur aktiven Region wird. In diesem Handbuch werden Designs mit Pilotlicht und Warmbetrieb nicht behandelt. Weitere Informationen finden Sie im Blogbeitrag Disaster Recovery (DR) Architecture on AWS, Teil III: Pilot Light and Warm Standby
Die Verwendung des Modus „In eine Region schreiben“ funktioniert gut, wenn Sie globale Tabellen für global verteilte Lesevorgänge mit niedriger Latenz verwenden. Ein Beispiel ist ein großes Social-Media-Unternehmen, das in allen Regionen der Welt dieselben Referenzdaten zur Verfügung haben muss. Sie aktualisieren die Daten nicht oft, aber wenn sie es tun, schreiben sie nur in eine Region, um mögliche Schreibkonflikte zu vermeiden. Lesevorgänge sind immer von jeder Region aus zulässig.
Nehmen wir als weiteres Beispiel das zuvor erwähnte Finanzdienstleistungsunternehmen, das die tägliche Cashback-Berechnung eingeführt hat. Sie verwendeten den Modus „In eine beliebige Region schreiben“, um den Saldo zu berechnen, aber „Schreiben in eine Region“, um Zahlungen nachzuverfolgen. Für diese Arbeit sind Transaktionen erforderlich, die in MRSC-Tabellen nicht unterstützt werden. Daher funktioniert sie besser mit einer separaten MREC-Tabelle und dem Schreiben in einen Regionsmodus.
