Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- bigdata:konsistenz [2015/10/01 15:09] – [BASE] brueck
+++ bigdata:konsistenz [2015/10/05 21:27] (aktuell) – [CAP-Theorem] 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.
-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:
-  * **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|Roe 2012]]).
+  * **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]]).
   * **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//.
@@ Zeile 35: / Zeile 35: @@
 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.
@@ Zeile 44: / Zeile 44: @@
 ===== CAP-Theorem =====
-Das **CAP-Theore**m wurde von Eric Brewer im Jahre 2000 vorgestellt (daher manchmal auch **Brewers Theorem** genannt) und 2002 von Seth Gilbert und Nancy Lynch bewiesen ([[bigdata:literatur|Gilbert/Lynch 2002]]).
+Das **CAP-Theore**m wurde von Eric Brewer im Jahre 2000 vorgestellt (daher manchmal auch **Brewers Theorem** genannt) und 2002 von Seth Gilbert und Nancy Lynch bewiesen ([[bigdata:literatur#g|Gilbert/Lynch 2002]]).
 **CAP** steht dabei für die Eigenschaften:
@@ Zeile 51: / Zeile 51: @@
 **Consistency** (Konsistenz)
-Nach einem schreibenden Zugriff haben alle verteilten Repliken auf sämtlichen Knoten immer denselben, aktuellen Datenzustand, so als ob dieser Zugriff eine atomare Operation auf einer Ein-Server-Instanz wäre ([[bigdata:literatur|Gilbert/Lynch 2002: S. 3]]). Wird direkt nach einem solchen Zugriff der Datenbestand abgefragt, liefert er entweder die aktualisierten Daten oder aber einen neuen Zustand, sollte in der Zwischenzeit ein erneutes Update erfolgt sein. Zu keiner Zeit aber einen älteren Datenstand.
+Nach einem schreibenden Zugriff haben alle verteilten Repliken auf sämtlichen Knoten immer denselben, aktuellen Datenzustand, so als ob dieser Zugriff eine atomare Operation auf einer Ein-Server-Instanz wäre ([[bigdata:literatur#g|Gilbert/Lynch 2002: S. 3]]). Wird direkt nach einem solchen Zugriff der Datenbestand abgefragt, liefert er entweder die aktualisierten Daten oder aber einen neuen Zustand, sollte in der Zwischenzeit ein erneutes Update erfolgt sein. Zu keiner Zeit aber einen älteren Datenstand.
 \\
 **Availability** (Verfügbarkeit)
-Das System muss zu jeder Zeit voll verfügbar sein, um möglichst schnell und effizient Anfragen bedienen zu können. Auf jede Anfrage an einen intakten Knoten muss auch eine Antwort erfolgen ([[bigdata:literatur|Gilbert/Lynch 2002: S. 3]]). Gerade bei Internetanwendungen spielt die Reaktionszeit eine wichtige Rolle. Längere Wartezeiten (schon ab einer Sekunde) können für (potentielle) Kunden schon Grund sein, einen Webshop zu verlassen oder zur Konkurrenz zu wechseln ([[bigdata:literatur|Borland 2013]]). Besonders kritisch wird das, sollte nach einer Zahlungsbestätigung eine Reaktion des Systems ausbleiben.
+Das System muss zu jeder Zeit voll verfügbar sein, um möglichst schnell und effizient Anfragen bedienen zu können. Auf jede Anfrage an einen intakten Knoten muss auch eine Antwort erfolgen ([[bigdata:literatur#g|Gilbert/Lynch 2002: S. 3]]). Gerade bei Internetanwendungen spielt die Reaktionszeit eine wichtige Rolle. Längere Wartezeiten (schon ab einer Sekunde) können für (potentielle) Kunden schon Grund sein, einen Webshop zu verlassen oder zur Konkurrenz zu wechseln ([[bigdata:literatur#b|Borland 2013]]). Besonders kritisch wird das, sollte nach einer Zahlungsbestätigung eine Reaktion des Systems ausbleiben.
 \\
 **Partition Tolerance** (Ausfallstoleranz)
-Auch wenn Knoten oder Kommunikationsverbindungen ausfallen sollten (geplant oder ungeplant) und das Cluster so in Partitionen teilt, muss das Gesamtsystem weiterhin lauffähig und einsatzbereit sein und kann im Notfall Aufgaben umleiten. Um dies zu ermöglichen, werden die Daten im Cluster [[bigdata:skalierung|repliziert]] und redundant auf unterschiedlichen Knoten gehalten. „Außer einem totalen Netzwerkausfall darf keinerlei Fehler dazu führen, dass ein System unvorschriftsmäßig reagiert“ (übersetzt nach [[bigdata:literatur|Gilbert/Lynch 2002: S. 4]]).
+Auch wenn Knoten oder Kommunikationsverbindungen ausfallen sollten (geplant oder ungeplant) und das Cluster so in Partitionen teilt, muss das Gesamtsystem weiterhin lauffähig und einsatzbereit sein und kann im Notfall Aufgaben umleiten. Um dies zu ermöglichen, werden die Daten im Cluster [[bigdata:skalierung|repliziert]] und redundant auf unterschiedlichen Knoten gehalten. „Außer einem totalen Netzwerkausfall darf keinerlei Fehler dazu führen, dass ein System unvorschriftsmäßig reagiert“ (übersetzt nach [[bigdata:literatur#g|Gilbert/Lynch 2002: S. 4]]).
 {{ :bigdata:nosql_cap.png?600 |}}
-(Grafik-Quelle: [[bigdata:literatur|Lee 2011]])
+(Grafik-Quelle: [[bigdata:literatur#l|Lee 2011]])
-Das Theorem besagt, dass in einem verteilten System mit Replikationen nur //**zwei**// der drei CAP-Eigenschaften zu erreichen sind (vgl. [[bigdata:literatur|Brewer 2012]]). Das bedeutet, ein System erfüllt entweder die Eigenschaften CA, AP oder CP.
+Das Theorem besagt, dass in einem verteilten System mit Replikationen nur //**zwei**// der drei CAP-Eigenschaften zu erreichen sind (vgl. [[bigdata:literatur#b|Brewer 2012]]). Das bedeutet, ein System erfüllt entweder die Eigenschaften CA, AP oder CP.
 Ein klassisches RDBMS setzt mit seinen ACID-Transaktionen vor allem auf allem auf Konsistenz, es ist ein CA-System. Ist es ein Ein-Server-System, so ist es verfügbar und konsistent, aber nicht ausfalltolerant. Ein einzelner Server kann nicht in Partitionen zerfallen und ist entweder verfügbar oder fällt ganz aus. Skaliert man dieses System mit [[bigdata:skalierung|Replikationen]], so leidet die Verfügbarkeit darunter, da es länger dauert, bis alle Daten aktualisiert wurden. Dies wird kritischer je größer ein solches Cluster wird.