Database Reference
In-Depth Information
Ein CAP-Abenteuer, Teil II: Schlussendliche Konsistenz
Spulen wir zwei Jahre zurück. Sie waren zu diesem Zeitpunkt drei Jahre auf der
Insel und Sie entdecken eine Flasche im Sand - wertvoller Kontakt zum Rest der
Welt. Sie entkorken die Flasche und frohlocken! Sie haben gerade etwas Wichtiges
erfahren . . .
Die Zahl von Beyoncés Studio-Alben ist von größter Bedeutung für das aggregierte
Wissen dieser Welt. Tatsächlich ist es so wichtig, dass bei jeder Veröffentlich ei-
nes neuen Albums jemand das aktuelle Datum und die Zahl auf ein Stück Papier
schreibt. Dieses Papier wird in eine Flasche gesteckt, die dann ins Meer geworfen
wird. Wenn jemand wie Sie auf einer einsamen Insel vom Rest der Welt abgetrennt
ist, besitzt er
schlussendlich
die richtige Antwort.
Zurück in die Gegenwart. Wenn der Schiffskapitän Sie jetzt fragt: „Wie viele Studio-
Alben hat Beyoncé?“, bleiben Sie
verfügbar
und antworten „drei“. Sie können zum
Rest der Welt
in
konsistent sein, doch Sie sind sich im Bezug auf Ihre Antwort recht
sicher, da noch keine weitere Flasche angespült wurde.
Die Geschichte endet damit, dass der Kapitän Sie rettet und Sie bei Ihrer Rückkehr
das neue Album vorfinden und glücklich bis ans Ende leben. Solange Sie an Land
bleiben, müssen Sie nicht partitionstolerant sein und können bis ans Ende aller
Tage konsistent und verfügbar sein.
A2.2 CAP in freier Wildbahn
Bei einigen partitionstoleranten Datenbanken kann man requestbezogen fest-
legen, ob sie eher konsistent oder eher verfügbar sein soll. Riak arbeitet so
und erlaubt den Clients bei einem Request zu entscheiden, welcher Grad an
Konsistenz benötigt wird. Die anderen Datenbanken belegen größtenteils die
eine oder andere Ecke im CAP-Kompromiss-Dreieck.
Redis, PostgreSQL und Neo4J sind konsistent und verfügbar (CA); sie ver-
teilen keine Daten, weshalb die Partitionierung kein Thema ist (und CAP
macht bei nicht verteilten Systemen zugegebenermaßen keinen Sinn). Mon-
goDB und HBase sind generell konsistent und partitionstolerant (CP). Im Fal-
le einer Partitionierung des Netzwerks können sie auf bestimmte Arten von
Queries möglicherweise nicht reagieren (zum Beispiel ist in einem Mongo-
Replica-Set
slaveok
für Leseoperationen auf „falsch“ gesetzt). In der Praxis
werden Hardwarefehler großzügig behandelt - andere noch vernetzte Kno-
ten können den ausgefallenen Server ersetzen - , doch aus Sicht des CAP-
Theorems sind sie nicht verfügbar. CouchDB ist schließlich verfügbar und
partitionstolerant (AP). Obwohl zwei oder mehr CouchDB-Server Daten un-
tereinander replizieren können, garantiert CouchDB die Konsistenz zwischen
irgendwelchen Servern nicht.
