Hallo zusammen und willkommen zurück.
Im heutigen Video werden wir nun über das Gesamtkonsistenzmodell diskutieren, das sich speziell
auf Dynamo DB bezieht.
Da Dynamo DB nun ein verwalteter Dienst in Dynamo DB ist, werden alle Ihre Daten auf der SSD gespeichert und automatisch
über mehrere Verfügbarkeitszonen in der Amazonas-Region repliziert, was wiederum die integrierte
Hochverfügbarkeit und Datendauerhaftigkeit bietet.
Beispiel: Sie haben hier drüben eine Dynamo DB-Tabelle und es gibt drei Verfügbarkeitszonen in der Region.
Wenn Sie jetzt hinter den Kulissen einige Daten zu Dynamo DB hinzufügen, werden diese Daten in allen
Verfügbarkeitszonen repliziert.
Falls nun eine der Verfügbarkeitszonen ausfällt, kann die Dynamo DB immer noch die Daten aus den anderen
Verfügbarkeitszonen hier drüben abrufen.
Eine wichtige Sache, an die Sie sich in dieser Phase erinnern sollten, ist die Konsistenzzeitachse.
Wenn also Ihre Anwendung die Daten in die Dynamo DB-Tabelle schreibt und eine 200-OK-Antwort erhält, ist das
Recht eingetreten und hinter den Kulissen dauerhaft.
Beachten Sie nun auch, dass diese geschriebenen Daten schließlich über den gesamten Speicherort hinweg konsistent sind, normalerweise
innerhalb einer Sekunde oder weniger.
Dies ist also sehr ähnlich zu dem, was wir besprechen, wenn Sie einige Daten in Dynamo DB schreiben, da sie
repliziert und über mehrere Verfügbarkeitszonen hinweg hinzugefügt werden, diese Daten schließlich über alle Speicherorte
hinweg konsistent sein werden.
Es ist nicht so, dass es in der gleichen Dauer Millisekunden sein kann.
Die Daten wären in der gesamten Verfügbarkeitszone konsistent.
Es kann vorkommen, dass Sie zu diesem Zeitpunkt sehen, dass diese neuen Daten in den beiden Verfügbarkeitszonen konsistent sind, aber sie
werden nicht in der Verfügbarkeitszone drei hinzugefügt, oder Sie können sagen, dass sie in der Verfügbarkeitszone drei
ab dieser Dauer nicht aktualisiert werden .
Gut.
Diese endgültige Konsistenz liegt also normalerweise innerhalb einer Sekunde oder weniger.
Jetzt kommt das wichtige Konzept der letztendlichen Konsistenz lesen.
Wenn Sie also die Daten aus der Dynamo DB-Tabelle lesen, spiegelt die Antwort möglicherweise nicht das Ergebnis des kürzlich
abgeschlossenen richtigen Vorgangs wider, und diese Antwort kann einige veraltete Daten oder einige ältere Daten enthalten.
Und wenn Sie Ihre Leseanfrage nach kurzer Zeit wiederholen, sollte die Antwort die neuesten Daten hier drüben
zurückgeben.
Dies ist also die Grundlage für ein eventuell konsistentes Lesen.
Jetzt haben Sie auch etwas, das als Strong Consistent Read bezeichnet wird.
Wenn Sie jetzt einen Strong Consistent Read anfordern, gibt Dynamo DB eine Antwort mit den aktuellsten Daten zurück, die
die Aktualisierungen aller vorherigen Schreibvorgänge widerspiegeln, die erfolgreich waren.
Lassen Sie uns also in Dynamo DB hier schnell eine neue Tabelle erstellen.
Wir verwenden eine benutzerdefinierte Einstellung und im Kapazitätsrechner hier haben Sie unter der Lesekonsistenz
schließlich konsistent, stark, konsistent sowie transaktional.
Für das heutige Video konzentrieren wir uns mehr auf schließlich konsistente und starke Konsistenz.
Dies untersuchen wir jetzt, während wir darüber diskutieren, dass „eventuell konsistent“ zu einigen veralteten Daten führen
kann, die auf einer sehr kürzlichen Kursoperation basieren, die im Dynamo aufgetreten ist.
DB Um dies zu überwinden, falls Sie überhaupt keine veralteten Daten benötigen, gibt es viele Anwendungen, bei
denen Sie sich veraltete Daten nicht leisten können.
In solchen Fällen können Sie also zu einer starken Konsistenz greifen.
In diesem Fall ist ein starker Konsistenzvorsprung möglicherweise nicht verfügbar, wenn es zu einer Netzwerkverzögerung oder einem
Ausfall kommt.
In diesem Fall gibt Dynamo DB sofort einen 500-Fehler zurück.
Zweitens ist starke Konsistenz.
Es kann eine höhere Latenz haben als die des eventuell konsistenten Rechts.
Und der dritte wichtige Punkt ist, dass starkes konsistentes Lesen mehr Durchsatzkapazität verbraucht als das letztendliche
konsistente Lesen.
Nun zu einer groben Übersicht, eine Sache, die Sie beachten müssen, ist, dass standardmäßig im Allgemeinen ein eventuell konsistentes
Lesen verwendet wird.
Sie können auch den Strong Consistent Read auswählen, der jedoch nicht mit zusätzlichen Kosten verbunden ist.
Lassen Sie uns beispielsweise fortfahren und den Satz von Werten hier für einen starken konsistenten Lesevorgang ändern.
Es kostet $25 pro Monat.
Wenn Sie das schließlich konsistente Lesen auswählen, kostet es 24 US-Dollar pro Monat.
Es sind also einige wichtige Dinge zu beachten, wenn wir diskutieren, dass Dynamo DB die eventuell konsistenten Lesevorgänge verwendet,
sofern Sie nicht fortfahren und etwas anderes angeben.
Daher bieten verschiedene Vorgänge wie Lesevorgänge im Zusammenhang mit dem Abrufen von Elementen, Abfragen und Scans einen konsistenten
Leseparameter.
Und diesen Parameter können Sie einstellen, um die starke konsistente Rate anzugeben.
Wenn Sie beispielsweise das Vergessenselement Dynamo DB SEAL Command verwenden, können Sie einen Bindestrich, einen Bindestrich, einen konsistenten Leser,
einen Krieger angeben, und dies wird fortfahren und den starken konsistenten Lesevorgang verwenden, um dieses Spezifische anzupassen.
Artikel, also lasst uns schnell einen Blick darauf werfen.
Im Dynamo-typischen Gate-Element, das im Wesentlichen Elemente aus der Dynamo-DB-Tabelle abruft, haben Sie also
die Möglichkeit, konsistent zu lesen und keine konsistente Rate.
Gehen wir ein bisschen runter.
Wenn Sie also hier in die Beschreibung schauen, heißt es bestimmt das Lesekonsistenzmodell.
Wenn es auf „true“ gesetzt ist, verwendet die Operation Strong Consistent Read.
Andernfalls verwendet die Operation das eventuelle konsistente Lesen.
So können Sie dies also auch als Teil Ihrer Bewerbung angeben, falls Sie dies wünschen.
Groß.
Das ist also die grobe Übersicht über das Konsistenzmodell.
Und damit endet das heutige Video.