Benutzer-Werkzeuge

Webseiten-Werkzeuge


bigdata:konsistenz

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Nächste Überarbeitung
Vorhergehende Überarbeitung
Letzte ÜberarbeitungBeide Seiten der Revision
bigdata:konsistenz [2015/10/01 15:02] – angelegt brueckbigdata:konsistenz [2015/10/05 21:25] – [BASE] brueck
Zeile 23: Zeile 23:
 **BASE** ist ebenfalls ein Akronym und stellt die gelockerten Konsistenzeigenschaften in [[bigdata:nosql|NoSQL-Systemen]] dar, die den strengen ACID-Anforderungen der RDBMS entgegenstehen. **BASE** ist ebenfalls ein Akronym und stellt die gelockerten Konsistenzeigenschaften in [[bigdata:nosql|NoSQL-Systemen]] dar, die den strengen ACID-Anforderungen der RDBMS entgegenstehen.
  
-Mit Ausnahme der Graphdatenbanken unterstützen die meisten NoSQL-Datenbanken keine Transaktionen. Grund dafür ist, dass es zu kompliziert wäre, volle ACID-Eigenschaften in einem Cluster zu unterstützen. Ein verteilter Datenbestand würde zu viel Kommunikationsoverhead bedeuten, der letztlich ihre Stärke, die Geschwindigkeit beim Umgang mit enormen Datenvolumen, zunichtemachen würde. Dafür verwalten diese Systeme Datensätze in Form von Aggregaten, innerhalb derer Updates atomar ausgeführt werden können, jedoch keine „Transaktionen“, die mehrere Aggregate umfassen (vgl. [[bigdata:literatur|Sadalage/Fowler 2012: S. 19f]]).+Mit Ausnahme der Graphdatenbanken unterstützen die meisten NoSQL-Datenbanken keine Transaktionen. Grund dafür ist, dass es zu kompliziert wäre, volle ACID-Eigenschaften in einem Cluster zu unterstützen. Ein verteilter Datenbestand würde zu viel Kommunikationsoverhead bedeuten, der letztlich ihre Stärke, die Geschwindigkeit beim Umgang mit enormen Datenvolumen, zunichtemachen würde. Dafür verwalten diese Systeme Datensätze in Form von Aggregaten, innerhalb derer Updates atomar ausgeführt werden können, jedoch keine „Transaktionen“, die mehrere Aggregate umfassen (vgl. [[bigdata:literatur#s|Sadalage/Fowler 2012: S. 19f]]).
  
 **BASE** steht für **B**asically **A**vailable, **S**oft State, **E**ventual Consistency: **BASE** steht für **B**asically **A**vailable, **S**oft State, **E**ventual Consistency:
  
-\\ +  * **Basically Available**: Systeme, die auf das BASE-Modell setzen, versprechen, hochverfügbar zu sein und zu jeder Zeit auf Anfragen reagieren zu können. Dafür machen sie Abstriche bei der Konsistenz (siehe dazu auch CAP-Theorem). Das bedeutet, dass ein System immer auf eine Anfrage reagiert. Die Antwort kann aber auch ein Fehler sein oder einen inkonsistenten Datenstand liefern ([[bigdata:literatur#r|Roe 2012]]).
-**Basically Available**+
  
-Systemedie auf das BASE-Modell setzenversprechen, hochverfügbar zu sein und zu jeder Zeit auf Anfragen reagieren zu können. Dafür machen sie Abstriche bei der Konsistenz (siehe dazu auch CAP-Theorem). Das bedeutetdass ein System immer auf eine Anfrage reagiert. Die Antwort kann aber auch ein Fehler sein oder einen inkonsistenten Datenstand liefern ([[bigdata:literatur|Roe 2012]]).+  * **Soft State**: Der Zustandin dem noch nicht alle Änderungen an das gesamte System propagiert wurdenaber trotzdem auf Anfragen reagieren kannnennt man auch //Soft State//
  
-\\ +  * **Eventual Consistency**Im Gegensatz zum strengen ACID-Modell wird in BASE die Konsistenz als eine Art "Übergang" betrachtet, sodass nach einem Update nicht sofort alle Partitionen aktualisiert werden, sondern erst nach einer gewissen Zeit. Das System wird also "**letztendlich konsistent**" (//eventually consistent//), aber bis dahin in einem inkonsistenten Übergangs-Zustand (//soft state//) sein.
-**Soft State** +
- +
-Der Zustand, in dem noch nicht alle Änderungen an das gesamte System propagiert wurden, aber trotzdem auf Anfragen reagieren kann, nennt man auch //Soft State//.  +
- +
-\\ +
-**Eventual Consistency** +
- +
-Im Gegensatz zum strengen ACID-Modell wird in BASE die Konsistenz als eine Art "Übergang" betrachtet, sodass nach einem Update nicht sofort alle Partitionen aktualisiert werden, sondern erst nach einer gewissen Zeit. Das System wird also "**letztendlich konsistent**" (//eventually consistent//), aber bis dahin in einem inkonsistenten Übergangs-Zustand (//soft state//) sein.+
  
 Ein Beispiel für eine Situation, in der keine unbedingte Konsistenz nötig ist, sind Social-Media-Seiten. Hier ist es nicht wirklich kritisch, wenn ein Status-Update nicht sofort für alle sichtbar ist oder ob eine Freundschaftsanfrage sofort als bestätigt markiert wird oder erst wenige Sekunden später. Ein Beispiel für eine Situation, in der keine unbedingte Konsistenz nötig ist, sind Social-Media-Seiten. Hier ist es nicht wirklich kritisch, wenn ein Status-Update nicht sofort für alle sichtbar ist oder ob eine Freundschaftsanfrage sofort als bestätigt markiert wird oder erst wenige Sekunden später.
  
-Dabei können einige Konsistenzmodelle gegeben sein (vgl. **Vogels 2008**):+Dabei können einige Konsistenzmodelle gegeben sein (vgl. [[bigdata:literatur#v|Vogels 2008]]):
  
   * **Read-Your-Writes Consistency**: Hat ein Prozess erst einmal einen Wert geändert, wird er niemals einen älteren Wert sehen.   * **Read-Your-Writes Consistency**: Hat ein Prozess erst einmal einen Wert geändert, wird er niemals einen älteren Wert sehen.
bigdata/konsistenz.txt · Zuletzt geändert: 2015/10/05 21:27 von brueck