Modus „Schreiben in eine beliebige Region“ (keine Primärregion)

Der Schreibmodus „In eine beliebige Region schreiben“ ist vollständig aktiv und schränkt nicht ein, wo ein Schreibvorgang stattfinden kann. Jede Region kann eine Schreibanfrage jederzeit annehmen. Dies ist der einfachste Modus. Er kann jedoch nur mit einigen Arten von Anwendungen verwendet werden. Es ist geeignet, wenn alle Schreiboperationen idempotent sind. Idempotent bedeutet, dass sie sicher wiederholbar sind, sodass gleichzeitige oder wiederholte Schreibvorgänge in verschiedenen Regionen nicht miteinander in Konflikt geraten, z. B. wenn ein Benutzer seine Kontaktdaten aktualisiert. Es funktioniert auch gut für einen Datensatz, der nur zum Anhängen verwendet wird, bei dem alle Schreiboperationen einzigartige Einfügungen unter einem deterministischen Primärschlüssel sind. Dies ist ein Sonderfall von idempotenter Eigenschaft. Schließlich ist dieser Modus geeignet, wenn das Risiko widersprüchlicher Schreiboperationen akzeptabel ist.

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 kürzlich durchgeführten Schreibvorgänge beliebig oft in jeder sekundären Region wiedergegeben werden können. Wenn möglich, sollten Sie diesen Schreibmodus vorsehen.

Beispielsweise verwenden mehrere Video-Streaming-Dienste globale Tabellen, um Lesezeichen, Rezensionen, Statuskennzeichnungen usw. zu verfolgen. Diese Bereitstellungen können den Modus „In jede Region schreiben“ verwenden, sofern sie sicherstellen, dass jeder Schreibvorgang idempotent ist. Dies ist der Fall, wenn bei jeder Aktualisierung — beispielsweise beim Einstellen eines neuen aktuellen Zeitcodes, beim Zuweisen einer neuen Bewertung oder beim Festlegen eines neuen Uhrenstatus — dem Benutzer direkt der neue Status zugewiesen wird und der nächste richtige Wert für ein Objekt nicht von seinem aktuellen Wert abhängt. Wenn die Schreibanforderungen des Benutzers zufällig an verschiedene Regionen weitergeleitet werden, bleibt der letzte Schreibvorgang bestehen und der globale Status wird entsprechend der letzten Zuweisung abgerechnet. Leseoperationen in diesem Modus werden irgendwann konsistent und werden um den neuesten ReplicationLatency Wert verzögert.

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. Diese Firma war in der Lage, den Modus „In jede Region schreiben“ mit einer sorgfältigen Neugestaltung zu verwenden. In der ersten Entwurfsskizze wurde ein einziger RunningBalance Artikel pro Kunde verwendet. Kundenaktionen aktualisierten den Saldo mit einem ADD Ausdruck, der nicht idempotent ist (weil der neue korrekte Wert vom aktuellen Wert abhängt), und der Saldo geriet aus dem Takt, wenn zwei Schreibvorgänge auf dieselbe Bilanz ungefähr zur gleichen Zeit in verschiedenen Regionen stattfanden. Bei der Neugestaltung wird Event-Streaming verwendet, das wie ein Ledger mit einem Workflow funktioniert, der nur zum Anhängen verwendet wird. Bei jeder Kundenaktion wird der Elementauflistung, die für diesen Kunden unterhalten wird, ein neues Element hinzugefügt. (Eine Elementsammlung ist eine Gruppe von Elementen, die einen gemeinsamen Primärschlüssel, aber unterschiedliche Sortierschlüssel haben.) Jeder Schreibvorgang ist eine idempotente Einfügung, die die Kunden-ID als Partitionsschlüssel und die Transaktions-ID als Sortierschlüssel verwendet. Dieses Design macht die Berechnung des Gleichgewichts schwieriger, da es erfordert, dass a Query die Elemente abruft, gefolgt von einigen clientseitigen Berechnungen, aber es macht alle Schreibvorgänge idempotent und führt zu erheblichen Vereinfachungen bei Routing und Failover. (Weitere Informationen werden weiter unten in diesem Handbuch im Detail diskutiert.

Ein drittes Beispiel betrifft ein Unternehmen, das Online-Anzeigenplatzierungsdienste anbietet. Dieses Unternehmen entschied, dass ein geringes Risiko eines Datenverlusts akzeptabel wäre, um die Konstruktionsvereinfachungen des Modus „Schreiben in jede Region“ zu erreichen. Wenn sie Anzeigen schalten, haben sie nur wenige Millisekunden Zeit, um genügend Metadaten abzurufen, um zu bestimmen, welche Anzeige geschaltet werden soll, und dann die Anzeigenimpressionen aufzuzeichnen, damit sie dieselbe Anzeige nicht bald wiederholen. Sie verwenden globale Tabellen, um sowohl Leseoperationen mit niedriger Latenz für Endbenutzer auf der ganzen Welt als auch Schreibvorgänge mit niedriger Latenz durchzuführen. Sie erfassen alle Anzeigenimpressionen für einen Nutzer in einem einzigen Element, das als wachsende Liste dargestellt wird. Sie verwenden ein Element, anstatt es an eine Artikelsammlung anzuhängen, sodass sie ältere Anzeigenimpressionen im Rahmen jedes Schreibvorgangs entfernen können, ohne für einen Löschvorgang bezahlen zu müssen. Dieser Schreibvorgang ist nicht idempotent. Wenn derselbe Endnutzer etwa zur gleichen Zeit Anzeigen aus mehreren Regionen sieht, besteht die Möglichkeit, dass ein Schreibvorgang für eine Anzeigenimpression einen anderen überschreibt. Das Risiko besteht darin, dass ein Nutzer eine Anzeige von Zeit zu Zeit wiederholt sieht. Sie entschieden, dass dies akzeptabel ist.