bigdata:konsistenz
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
bigdata:konsistenz [2015/10/01 15:02] – angelegt 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**: Systeme, die auf das BASE-Modell setzen, versprechen, |
- | **Basically Available** | + | |
- | Systeme, die auf das BASE-Modell setzen, versprechen, | + | * **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// | + | |
- | + | ||
- | \\ | + | |
- | **Eventual Consistency** | + | |
- | Im Gegensatz zum strengen ACID-Modell wird in BASE die Konsistenz als eine Art " | + | * **Eventual Consistency**: |
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 53: | 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 60: | 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