bigdata:konsistenz
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende Überarbeitung | ||
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: | **BASE** ist ebenfalls ein Akronym und stellt die gelockerten Konsistenzeigenschaften in [[bigdata: | ||
- | 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, | + | 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, |
**BASE** steht für **B**asically **A**vailable, | **BASE** steht für **B**asically **A**vailable, | ||
- | * **Basically Available**: | + | * **Basically Available**: |
* **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// | * **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. | 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: |
* **Read-Your-Writes Consistency**: | * **Read-Your-Writes Consistency**: | ||
Zeile 44: | Zeile 44: | ||
===== CAP-Theorem ===== | ===== 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: | + | 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: |
**CAP** steht dabei für die Eigenschaften: | **CAP** steht dabei für die Eigenschaften: | ||
Zeile 51: | Zeile 51: | ||
**Consistency** (Konsistenz) | **Consistency** (Konsistenz) | ||
- | Nach einem schreibenden Zugriff haben alle verteilten Repliken auf sämtlichen Knoten immer denselben, aktuellen Datenzustand, | + | Nach einem schreibenden Zugriff haben alle verteilten Repliken auf sämtlichen Knoten immer denselben, aktuellen Datenzustand, |
\\ | \\ | ||
**Availability** (Verfügbarkeit) | **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: | + | 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: |
\\ | \\ | ||
**Partition Tolerance** (Ausfallstoleranz) | **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, | + | 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, |
{{ : | {{ : | ||
- | (Grafik-Quelle: | + | (Grafik-Quelle: |
- | Das Theorem besagt, dass in einem verteilten System mit Replikationen nur // | + | Das Theorem besagt, dass in einem verteilten System mit Replikationen nur // |
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, | 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, |
bigdata/konsistenz.txt · Zuletzt geändert: 2015/10/05 21:27 von brueck