Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- bigdata:konsistenz [2015/10/05 21:25] – [BASE] brueck
+++ bigdata:konsistenz [2015/10/05 21:27] (aktuell) – [CAP-Theorem] brueck
@@ 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.