web-dev-qa-db-de.com

Eventuelle Konsistenz in einfachem Englisch

Ich höre oft über die eventuelle Konsistenz in verschiedenen Reden über NoSQL, Datenraster usw. .__ Es scheint, dass die Definition der eventuellen Konsistenz in vielen Quellen variiert (und möglicherweise sogar von einem konkreten Datenspeicher abhängt).

Kann jemand eine einfache Erklärung dazu geben, was Eventual Consistency allgemein ist und nicht mit einem konkreten Datenspeicher zusammenhängt?

90
Roman

Eventuelle Konsistenz:

  1. Ich schaue mir den Wetterbericht an und erfahre, dass es morgen regnen wird.
  2. Ich sage dir, dass es morgen regnen wird.
  3. Ihr Nachbar sagt seiner Frau, dass es morgen sonnig sein wird.
  4. Sie sagen Ihrem Nachbarn, dass es morgen regnen wird.

Irgendwann kennen alle Server (Sie, ich, Ihr Nachbar) die Wahrheit (dass es morgen regnen wird), aber in der Zwischenzeit kam der Kunde (seine Frau) in der Meinung, es sei sonnig, obwohl sie gefragt hatte nachdem einer oder mehrere der Server (Sie und ich) einen aktuelleren Wert hatten.

Im Gegensatz zu strikter Konsistenz/ACID-Konformität:

  1. Ihr Kontostand beträgt $ 50.
  2. Sie zahlen 100 € ein.
  3. Ihr von einem beliebigen Geldautomaten aus abgefragter Bankguthaben beträgt 150 US-Dollar.
  4. Ihre Tochter zieht $ 40 mit Ihrer Bankomatkarte ab.
  5. Ihr von einem beliebigen Geldautomaten aus abgefragter Bankguthaben beträgt 110 US-Dollar.

Ihr Kontostand kann zu keinem Zeitpunkt etwas anderes als die tatsächliche Summe aller Transaktionen, die zu diesem Zeitpunkt auf Ihrem Konto vorgenommen wurden, widerspiegeln.

reasonWarum viele NoSQL-Systeme eine eventuelle Konsistenz haben, besteht darin, dass praktisch alle von ihnen für die Verteilung ausgelegt sind. Bei vollständig verteilten Systemen ist der Aufwand für die Aufrechterhaltung der strengen Konsistenz superlinear (dh Sie können nur.) Skalieren Sie so weit, bevor sich die Dinge verlangsamen, und wenn dies erforderlich ist, müssen Sie exponentiell mehr Hardware auf das Problem werfen, um die Skalierung fortzusetzen.

157
Chris Shain

Eventuelle Konsistenz:

  1. Ihre Daten werden auf mehreren Servern repliziert
  2. Ihre Clients können auf alle Server zugreifen, um die Daten abzurufen
  3. Jemand schreibt Daten auf einen der Server, diese wurden jedoch noch nicht auf den Rest kopiert
  4. Ein Client greift mit den Daten auf den Server zu und erhält die aktuellste Kopie
  5. Ein anderer Client (oder sogar derselbe Client) greift auf einen anderen Server (einer, der die neue Kopie noch nicht erhalten hat) auf und erhält die alte Kopie

Da das Replizieren der Daten auf mehreren Servern einige Zeit in Anspruch nimmt, werden Anforderungen zum Lesen der Daten möglicherweise mit einer neuen Kopie an einen Server und dann an einen Server mit einer alten Kopie gesendet. Der Begriff "eventual" bedeutet, dass die Daten schließlich auf alle Server repliziert werden und somit alle über die aktuelle Kopie verfügen.

Eventuelle Konsistenz ist ein Muss, wenn Sie Lesevorgänge mit niedriger Latenz wünschen, da der antwortende Server seine eigene Kopie der Daten zurückgeben muss und keine Zeit hat, andere Server zu konsultieren und sich auf den Inhalt der Daten zu einigen. Ich schrieb einen blog post , der dies ausführlicher erklärt.

81
Ezra Hoch

Stellen Sie sich vor, Sie haben eine Anwendung und ihre Nachbildung. Dann müssen Sie der Anwendung ein neues Datenelement hinzufügen. 

 enter image description here

Anschließend synchronisiert die Anwendung die Daten mit anderen Replikatsymbolen

 enter image description here

In der Zwischenzeit erhält der neue Client Daten von einer Replik, die noch nicht aktualisiert wurde. In diesem Fall kann er keine korrekten Aktualisierungsdaten erhalten. Weil die Synchronisation etwas Zeit braucht. In diesem Fall hat es nicht eventuell Konsistenz

Problem ist, wie können wir schließlich Konsistenz?

Dazu verwenden wir eine Mediator-Anwendung zum Aktualisieren/Erstellen/Löschen von Daten und zum direkten Lesen von Daten. die helfen, eventuell Konsistenz 

 enter image description here  enter image description here

6
wthamira

Wenn eine Anwendung ein Datenelement auf einem Computer ändert, muss diese Änderung an die anderen Replikate weitergegeben werden. Da die Änderungsausbreitung nicht sofort erfolgt, gibt es ein Zeitintervall, in dem einige Kopien die letzte Änderung haben werden, andere jedoch nicht. Mit anderen Worten, die Kopien sind inkonsistent. Die Änderung wird jedoch letztendlich auf alle Kopien übertragen und daher der Begriff „eventuelle Konsistenz“. Der Begriff "eventuelle Konsistenz" ist einfach eine Bestätigung, dass es eine unbegrenzte Verzögerung bei der Weitergabe einer auf einem Computer vorgenommenen Änderung auf alle anderen Kopien gibt. Die eventuelle Konsistenz ist in zentralen Systemen (Einzelkopie) nicht sinnvoll oder relevant, da keine Weitergabe erforderlich ist.

quelle: http://www.Oracle.com/technetwork/products/nosqldb/documentation/consistency-explained-1659908.pdf

3
Alice

Im einfachen Englisch können wir sagen: Obwohl sich Ihr System möglicherweise in inkonsistenten Zuständen befindet, ist es immer das Ziel, für jeden Datenbestand irgendwann eine Konsistenz zu erreichen. 

Eventuelle Konsistenz ähnelt eher einem Spektrum. Auf der einen Seite haben Sie eine starke Konsistenz und auf der anderen Seite haben Sie eine eventuelle Konsistenz. Dazwischen gibt es Level wie Snapshot, lese meine Schriften, begrenzte Stalheit. Doug Terry hat eine schöne Erklärung in seinem Artikel über die eventuelle Beständigkeit durch Baseball .

Bei mir ist die Konsistenz im Allgemeinen die Toleranz für zufällige Daten in zufälliger Reihenfolge, wenn Sie aus einem Datenspeicher lesen. Alles, was besser ist, ist ein stärkeres Konsistenzmodell. Ein Snapshot enthält beispielsweise veraltete Daten, gibt jedoch dieselben Daten zurück, wenn sie erneut gelesen werden. Dies ist vorhersehbar. Manchmal kann die Anwendung Daten tolerieren, die für eine bestimmte Zeitdauer veraltet sind, über die hinaus konsistente Daten verlangt werden.

Wenn Sie die Bedeutung der Konsistenz betrachten, bezieht sich dies eher auf die Einheitlichkeit oder das Fehlen von Abweichungen. In Nicht-Computersystemen kann es also zu unerwarteten Abweichungen Toleranz bedeuten. Es könnte sehr gut durch ATM erklärt werden. Ein Geldautomat könnte offline sein und daher vom Kontostand von den Kernsystemen abweichen. Es gibt jedoch eine Toleranz für das Anzeigen verschiedener Waagen für ein Zeitfenster. Sobald der Geldautomat online ist, kann er sich mit den Kernsystemen synchronisieren und das gleiche Gleichgewicht wiedergeben. Man könnte sagen, dass ein Geldautomat letztendlich konsistent ist.

0
Shripad

Eventuell bedeutet Konsistenz, dass Änderungen Zeit benötigen, um sich zu verbreiten, und die Daten befinden sich möglicherweise nach jeder Aktion nicht im selben Status, selbst für identische Aktionen oder Transformationen der Daten. Dies kann dazu führen, dass sehr schlechte Dinge passieren, wenn Menschen nicht wissen, was sie tun. 

EX: Entwickler und sogar Architekten, die die Technologie nicht kennen oder verstehen und Angst haben, das zuzugeben, aus Angst, ihren Job zu verlieren, aber klassisch im RDBMS ausgebildet wurden und nur ACID-Systeme kennen (wie unterschiedlich kann das sein?) Und wer sich dafür einsetzt Wenn Sie die Technologie nicht kennen oder sich die Zeit nehmen, um sie zu erlernen, wird der Entwurf eines Dokumentdatenspeichers verpassen. Sie können es auch als RDBMS oder für das Zwischenspeichern verwenden. Sie werden die atomaren Transaktionen, die für ein gesamtes Dokument ausgeführt werden sollten, in „relationale“ Teile zerlegen, wobei vergessen wird, dass Replikations- und Latenzzeiten Dinge sind oder, was noch schlimmer ist, Dritte Systeme in eine „Transaktion“ ziehen. Sie tun dies, damit ihr RDBMS ihre Daten spiegeln kann, unabhängig davon, ob es funktioniert oder nicht, und ohne Tests, weil sie wissen, was sie tun. Dann werden sie überrascht, wenn komplexe Objekte, die in separaten Dokumenten wie „Bestellungen“ gespeichert sind, weniger „Auftragspositionen“ haben als erwartet oder gar nicht. Aber es wird nicht oft oder so oft vorkommen, dass sie nur vorwärts marschieren. Sie können das Entwicklungsproblem nicht einmal treffen. Anstatt Dinge neu zu entwerfen, werfen sie dann „Verzögerungen“ und „Wiederholungen“ und „Überprüfungen“ ein, um ein relationales Datenmodell zu fälschen, das nicht funktioniert, aber zusätzliche Komplexität ohne Nutzen hinzufügt. Aber jetzt ist es zu spät - die Sache wurde eingesetzt und jetzt läuft das Geschäft. Schließlich wird das gesamte System verworfen, die Abteilung ausgelagert und von einer anderen Person gepflegt. Es funktioniert immer noch nicht richtig, aber sie können kostengünstiger ausfallen als der aktuelle Ausfall.

Kurz gesagt, wenn Sie fragen müssen, müssen Sie viel lernen. Bitte setzen Sie nichts Geschäftskritisches um, bis Sie dies tun. Die Implementierung einer Implementierung eines Dokumentdatenspeichers ist viel schwieriger zu beheben als ein relationales Modell, da die grundlegenden Dinge, die in die Irre geführt werden, nicht einfach repariert werden können, da die für die Korrektur erforderlichen Dinge im Ökosystem nicht vorhanden sind. Das Refactoring der Daten eines Inflight-Stores ist auch viel schwieriger als die einfachen etl-Transformationen eines RDBMS.

Nicht alle Dokumentenspeicher werden gleich erstellt. Einige dieser Tage (MongoDB) unterstützen zwar eine bestimmte Art von Transaktionen, die Migration von Datastores ist jedoch wahrscheinlich mit den Kosten für die Neuimplementierung vergleichbar.

0
ggb667