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 sind auf Tabellenebene immer aktiv-aktiv. Vielleicht möchten Sie sie jedoch als aktiv-passiv behandeln, indem Sie steuern, wie Schreibanforderungen weitergeleitet werden. Sie könnten sich beispielsweise dafür entscheiden, Schreibanforderungen an eine einzelne Region weiterzuleiten, um mögliche Schreibkonflikte zu vermeiden.
Es gibt drei Hauptkategorien von verwalteten Schreibmustern:
Modus „Schreiben in eine beliebige Region“ (keine Primärregion)
Modus „Schreiben in eine Region“ (einzelne Primärregion)
Modus „Schreiben in Ihre Region“ (gemischte Primärregion)
Sie sollten überlegen, welches Schreibmuster zu Ihrem Anwendungsfall passt. Diese Wahl wirkt sich auf die Weiterleitung von Anforderungen, die Evakuierung einer Region und die Notfallwiederherstellung aus. Generell können sich die bewährten Methoden je nach Schreibmodus Ihrer Anwendung unterscheiden.
Modus „Schreiben in eine beliebige Region“ (keine Primärregion)
Der Modus Schreiben in eine beliebige Region ist vollständig aktiv-aktiv. In diesem Modus bestehen keine Einschränkungen in Bezug darauf, wo ein Schreibvorgang stattfinden kann. Jede Region kann jederzeit Schreibvorgänge akzeptieren. Dies ist der einfachste Modus. Dieser Modus kann nur bei einigen Arten von Anwendungen verwendet werden. Er ist geeignet, wenn alle Writer idempotent und daher sicher wiederholbar sind, sodass gleichzeitige oder wiederholte Schreibvorgänge in verschiedenen Regionen nicht miteinander in Konflikt geraten. Er kann beispielsweise verwendet werden, wenn ein Benutzer seine Kontaktdaten aktualisiert. Dieser Modus eignet sich auch gut für einen Sonderfall der Idempotenz, einen Append-Only-Datensatz, bei dem alle Schreibvorgänge eindeutige Einfügungen unter einem deterministischen Primärschlüssel sind. Schließlich ist dieser Modus geeignet, wenn das Risiko von Schreibkonflikten akzeptabel wäre.
Der Modus Schreiben in eine beliebige Region ist die am einfachsten zu implementierende Architektur. Die Weiterleitung ist einfacher, da jede Region jederzeit Schreibziel sein kann. Ein Failover ist einfacher, da alle letzten Schreibvorgänge beliebig oft in jeder sekundären Region wiederholt werden können. Wenn möglich, sollten Sie diesen Schreibmodus vorsehen.
Video-Streaming-Services beispielsweise verwenden häufig globale Tabellen, um Lesezeichen, Bewertungen, Ansehstatus-Flags usw. zu verfolgen. Diese Bereitstellungen können den Modus Schreiben in eine beliebige Region verwenden, solange sie sicherstellen, dass jeder Schreibvorgang idempotent ist und der nächste korrekte Wert für ein Element nicht von seinem aktuellen Wert abhängt. Dies ist bei Benutzer-Updates der Fall, bei denen der neue Status des Benutzers direkt zugewiesen wird, z. B. beim Einstellen eines neuen aktuellen Zeitcodes, beim Zuweisen einer neuen Bewertung oder bei der Einstellung eines neuen Ansehstatus. Wenn die Schreibanforderungen des Benutzers an verschiedene Regionen weitergeleitet werden, bleibt der letzte Schreibvorgang bestehen und der globale Status wird entsprechend der letzten Zuweisung festgelegt. Leseoperationen in diesem Modus werden schließlich konsistent, nachdem sie um den letzten ReplicationLatency-Wert verzögert wurden.
In einem anderen Beispiel verwendet ein Finanzdienstleistungsunternehmen globale Tabellen als Teil eines Systems, um eine laufende Aufstellung der Debitkartenkäufe für jeden Kunden zu führen und die Cashback-Prämien des Kunden zu berechnen. Neue Transaktionen gehen aus der ganzen Welt ein und gelangen in mehrere Regionen. Für ihr aktuelles Design, das die Vorteile globaler Tabellen nicht nutzt, verwenden sie einen einzigen Running Balance-Artikel pro Kunde. Bei Kundenaktionen wird der Saldo mit einem ADD-Ausdruck aktualisiert, der nicht idempotent ist, da der neue korrekte Wert vom aktuellen Wert abhängt. Das bedeutet, dass der Saldo nicht mehr synchron wäre, wenn zwei Schreibvorgänge in denselben Saldo ungefähr zur gleichen Zeit in verschiedenen Regionen stattfinden würden.
Dieselbe Firma könnte nach einer sorgfältigen Neugestaltung mit globalen Tabellen von DynamoDB den Modus Schreiben in eine beliebige Region verwenden. Das neue Design könnte einem „Ereignis-Streaming“-Modell folgen – im Wesentlichen einem Ledger mit einem Append-Only-Workflow. Bei jeder Kundenaktion wird der Elementauflistung, die für diesen Kunden unterhalten wird, ein neues Element hinzugefügt. Bei der Elementauflistung handelt es sich um eine Reihe von Elementen mit gemeinsamem Primärschlüssel, aber unterschiedlichen Sortierschlüsseln. Jede Schreibaktion, bei der die Kundenaktion angehängt wird, ist eine idempotente Einfügung, bei der die Kunden-ID als Partitionsschlüssel und die Transaktions-ID als Sortierschlüssel verwendet werden. Bei diesem Design ist die Berechnung des Saldos aufwendiger, da zunächst eine Query zum Abrufen der Elemente und dann einige Client-seitige Berechnungen erforderlich sind. Der Vorteil ist jedoch, dass dadurch alle Schreibvorgänge idempotent werden, wodurch Weiterleitungen und Failover erheblich vereinfacht werden. Weitere Informationen finden Sie unter Anforderungsweiterleitung mit globalen DynamoDB-Tabellen.
Nehmen wir als drittes Beispiel einen Kunden, der Online-Anzeigen platziert. Der Kunde hat entschieden, dass ein geringes Risiko eines Datenverlusts akzeptabel wäre, um die Designvereinfachungen des Modus Schreiben in eine beliebige Region zu erreichen. Wenn Anzeigen geschaltet werden, bleiben nur wenige Millisekunden Zeit, um genügend Metadaten abzurufen, um zu bestimmen, welche Anzeige geschaltet werden soll, und dann die Ad Impressions aufzuzeichnen, damit dem betreffenden Benutzer nicht mehrmals dieselbe Anzeige präsentiert wird. Mit globalen Tabellen kann das Unternehmen sowohl Lesevorgänge mit niedriger Latenz für Endbenutzer auf der ganzen Welt als auch Schreibvorgänge mit niedriger Latenz erzielen. Alle Ad Impressions für einen Benutzer können in einem einzelnen Element aufgezeichnet werden und dieses kann als wachsende Liste dargestellt werden. Das Unternehmen kann ein Element verwenden, anstatt Elemente an eine Elementauflistung anzuhängen, da auf diese Weise ältere Ad Impressions im Rahmen jedes Schreibvorgangs entfernt werden können, ohne dass Kosten für eine Löschung anfallen. Dieser Schreibvorgang ist NICHT idempotent. Wenn also derselbe Endbenutzer Anzeigen aus mehreren Regionen ungefähr zur gleichen Zeit sieht, besteht die Möglichkeit, dass ein Schreibvorgang für eine Ad Impression den anderen überschreibt. Bei der Platzierung von Online-Anzeigen lohnt es sich, das Risiko einzugehen, dass Benutzern gelegentlich eine wiederholte Anzeige präsentiert wird, um dieses einfachere und effizientere Design nutzen zu können.
Einzelne Primärregion („Schreiben in eine Region“)
Der Modus Schreiben in eine Region ist aktiv-passiv. Alle Schreibvorgänge in der Tabelle werden an eine einzelne aktive Region weitergeleitet. Beachten Sie, dass DynamoDB das Konzept einer einzelnen aktiven Region nicht kennt. Die Anwendungsweiterleitung außerhalb von DynamoDB verwaltet dies. Im Modus Schreiben in eine Region werden Schreibkonflikte vermieden, indem sichergestellt wird, dass Schreibvorgänge jeweils nur in eine Region gelangen. Dieser Schreibmodus ist hilfreich, wenn Sie bedingte Ausdrücke oder Transaktionen verwenden möchten, da diese nur funktionieren, wenn Sie wissen, dass Sie mit den neuesten Daten arbeiten. Bei Verwendung bedingter Ausdrücke und Transaktionen müssen also alle Schreibanforderungen an die Region mit den neuesten Daten gesendet werden.
Letztendlich konsistente Lesevorgänge können an alle Replikatregionen geleitet werden, um geringere Latenzen zu erreichen. Strikt konsistente Lesevorgänge müssen an die einzelne Primärregion geleitet werden.
Manchmal ist es notwendig, die aktive Region als Reaktion auf einen regionalen Fehler zu ändern, um mit Daten zu helfen. Evakuieren einer Region mit globalen DynamoDB-Tabellenist ein Beispiel für diesen Anwendungsfall. Manche Kunden ändern die gerade aktive Region regelmäßig, z. B. im Rahmen einer „Follow-the-Sun“-Bereitstellung. Dabei befindet sich die aktive Region in der Nähe der Gegend mit der höchsten Aktivität, sodass Lese- und Schreibvorgänge mit geringster Latenz möglich sind. Ein Nebeneffekt dabei ist, dass der Codepfad zum Ändern der Region täglich aufgerufen wird und damit vor einer Notfallwiederherstellung gründlich getestet wurde.
Die passive(n) Region(en) kann/können eine verkleinerte Infrastruktur rund um DynamoDB beibehalten, die nur dann aufgebaut wird, wenn sie zur aktiven Region werden sollte. Eine eingehendere Erläuterung von Konzepten für Pilotbetrieb und Warmbereitschaftsmodus finden Sie unter Disaster Recovery (DR) -Architektur unter AWS, Teil III: Pilotlicht und Warm-Standby
Der Modus Schreiben in eine Region ist gut geeignet, wenn globale Tabellen für global verteilte Lesevorgänge mit niedriger Latenz genutzt werden. Nehmen wir als Beispiel ein großes Social-Media-Unternehmen mit Millionen von Benutzern und Milliarden von Posts. Jeder Benutzer wird zum Zeitpunkt der Kontoerstellung einer Region zugewiesen, die sich geografisch in der Nähe seines Standorts befindet. In diese nicht globale Tabelle gelangen all Daten des Benutzers. Das Unternehmen verwendet eine separate globale Tabelle, um die Zuordnung der Benutzer zu ihren Heimatregionen zu speichern. Dabei wird der Modus Schreiben in eine Region verwendet. Weltweit werden schreibgeschützte Kopien unterhalten, um die Daten jedes Benutzers mit minimaler zusätzlicher Latenz direkt finden zu können. Aktualisierungen finden nur selten statt (nur wenn sich die Heimatregion eines Benutzers ändert) und erfolgen immer über eine Region, um Schreibkonflikte zu vermeiden.
Ein weiteres Beispiel ist ein Finanzdienstleistungskunde, der eine tägliche Cashback-Berechnung eingeführt hat. Der Kunde verwendet den Modus Schreiben in eine beliebige Region, um den Saldo zu berechnen, aber den Modus Schreiben in eine Region, um die tatsächlichen Cashback-Zahlungen zu verfolgen. Wenn das Unternehmen einen Kunden mit 1 Cent für jede pro Tag ausgegebenen 10 USD belohnen möchte, muss es eine Query für alle Transaktionen des Vortages durchführen, den Gesamtbetrag berechnen, die Cashback-Entscheidung in eine neue Tabelle schreiben, die abgefragten Elemente löschen, um sie als verbraucht zu markieren, und sie durch ein einzelnes Element ersetzen, in dem der Restbetrag gespeichert ist, der in die Berechnungen des nächsten Tages einfließen soll. Hierfür sind Transaktionen notwendig, daher ist der Modus Schreiben in eine Region besser geeignet. Eine Anwendung kann verschiedene Schreibmodi verwenden, sogar in derselben Tabelle, solange keine Gefahr überlappender Workloads besteht.
Gemischte Primärregion („Schreiben in Ihre Region“)
Im Modus Schreiben in Ihre Region werden verschiedenen Regionen unterschiedliche Datenteilmengen zugewiesen. Schreiboperationen sind für Elemente nur über die Heimatregion zulässig. Dieser Modus ist aktiv-passiv, die aktive Region wird jedoch auf der Grundlage des Elements zugewiesen. Jede Region ist Primärregion für ihren eigenen, sich nicht überlappenden Datensatz und Schreibvorgänge müssen überwacht werden, um eine korrekte Lokalisierung sicherzustellen.
Dieser Modus ist ähnlich wie der Modus Schreiben in eine Region, mit der Ausnahme, dass Schreibvorgänge mit geringerer Latenz möglich sind, da die jedem Endbenutzer zugeordneten Daten in größerer Netzwerknähe zu diesem Benutzer platziert werden können. Auch ist die umliegende Infrastruktur gleichmäßiger auf die Regionen verteilt und der Aufbau der Infrastruktur während eines Failover-Szenarios ist weniger aufwendig, da in allen Regionen ein Teil der Infrastruktur bereits aktiv ist.
Die Heimatregion für Elemente kann auf verschiedene Weise ermittelt werden:
Intrinsisch: Einige Aspekte der Daten machen deutlich, zu welcher Region sie gehören, etwa ihr Partitionsschlüssel. Ein Kunde und alle Daten zu diesem Kunden würden beispielsweise in den Kundendaten als zu einer bestimmten Region gehörend gekennzeichnet. Diese Technik wird unter Verwenden von Region Pinning, um eine Heimatregion für Elemente in einer globalen Amazon-DynamoDB-Tabelle festzulegen
beschrieben. Ausgehandelt: Die Heimatregion jedes Datensatzes wird extern ausgehandelt, z. B. mit einem separaten globalen Dienst, der die Zuweisungen verwaltet. Die Zuweisung kann begrenzt gültig sein. Danach muss sie neu verhandelt werden.
Tabellenorientiert: Anstelle einer einzelnen replizierenden globalen Tabelle können Sie so viele globale Tabellen verwenden, wie es replizierende Regionen gibt. Der Name jeder Tabelle gibt ihre Heimatregion an. Bei Standardoperationen werden alle Daten in die Heimatregion geschrieben, während andere Regionen eine schreibgeschützte Kopie behalten. Während eines Failovers übernimmt eine andere Region vorübergehend Schreibaufgaben für diese Tabelle.
Stellen Sie sich beispielsweise vor, Sie arbeiten für ein Gaming-Unternehmen. Sie benötigen eine niedrige Latenz bei Lese- und Schreibvorgängen für alle Spieler weltweit. Sie können jeden Spieler der ihm am nächsten gelegenen Region zuweisen. In dieser Region werden alle Lese- und Schreibvorgänge vorgenommen, sodass stets eine hohe read-after-write Konsistenz gewährleistet ist. Wenn der betreffende Spieler jedoch verreist oder es in seiner Heimatregion zu einem Ausfall kommt, steht eine vollständige Kopie seiner Daten in anderen Regionen zur Verfügung. So kann der Spieler nach Bedarf einer anderen Heimatregion zugewiesen werden.
Stellen Sie sich als weiteres Beispiel vor, Sie arbeiten in einem Videokonferenzunternehmen. Die Metadaten jeder Telefonkonferenz werden einer bestimmten Region zugewiesen. Anrufer können die ihnen am nächsten gelegene Region verwenden, um eine möglichst niedrige Latenz zu erzielen. Wenn eine Region ausfällt, ermöglicht die Verwendung globaler Tabellen eine schnelle Wiederherstellung, da das System die Verarbeitung des Anrufs an eine andere Region weitergeben kann, in der sich bereits eine replizierte Kopie der Daten befindet.
