Das CAP-Theorem - Sieben Wochen, sieben Datenbanken - page 348

Ein CAP Abenteuer, Teil I: CAP
Stellen Sie sich die Welt als riesiges verteiltes Datenbanksystem vor. Alles Land der
Welt enthält Informationen zu bestimmten Themen, und solange Sie sich irgendwie
in der Nähe von Menschen oder Technik aufhalten, erhalten Sie Antworten auf ihre
FIagen.
Nehmen wir nun an, Sie sind leidenschaftlicher Beyoncé-Knowles-Fan und es ist
der 5. September 2006. Während Sie mit Ihren Freunden auf einer Strandparty die
Veröffentlichung von Beyoncés zweitem Studio-Album feiern, werden Sie von einer
plötzlichen Flutwelle auf das Meer hinausgespült. Sie können sich auf ein behelfs-
mäßiges Floß retten und werden Tage später an einer einsamen Insel angespült.
Ohne eine Möglichkeit zur Kommunikation sind Sie effektiv vom Rest des Systems
(der Welt) abgetrennt ( partitioniert ). Dort warten Sie fünf lange Jahre . . .
Eines Morgens im Jahr 2011 erwachen Sie durch Rufe vom Meer. Der Kapitän eines
alten Schoners hat Sie entdeckt! Nach all diesen Jahren beugt sich der Kapitän über
die Reling und brüllt: „Wie viele Studio-Alben hat Beyoncé gemacht?“
Sie müssen nun eine Entscheidung treffen. Sie können die Frage mit dem letzten
Wert beantworten, den Sie haben (und der fünf Jahre alt ist). Oder Sie können eine
Antwort verweigern, weil Sie wissen, dass Sie abgeschnitten waren und Ihre Ant-
wort daher möglicherweise mit dem Rest der Welt nicht konsistent ist. Der Kapitän
bekommt keine Antwort, aber der Zustand der Welt bleibt konsistent (wenn er nach
Hause segelt, bekommt er die richtige Antwort). In Ihrer Rolle als abgefragter Kno-
ten können Sie die Daten der Welt konsistent halten oder verfügbar sein, aber nicht
beides .
A2.1 Schlussendliche Konsistenz
Verteilte Datenbanken müssen partitionstolerant sein, daher kann die Wahl
zwischen Verfügbarkeit und Konsistenz schwierig sein. Wenn Sie sich für Ver-
fügbarkeit entscheiden, ist nach CAP keine echte Konsistenz möglich, doch
Sie können dennoch schlussendliche Konsistenz bieten.
Die Idee hinter schlussendlicher Konsistenz ist, dass jeder Knoten immer
verfügbar ist, um Requests zu beantworten. Als Kompromiss werden Modifi-
kationen an den Daten im Hintergrund an andere Knoten weitergegeben. Das
bedeutet, dass das System zu jeder Zeit inkonsistent sein kann, die Daten
aber dennoch größtenteils richtig sind.
Der Domain Name Service (DNS) des Internets ist ein erstklassiges Beispiel
für ein schlussendlich konsistentes System. Sie registrieren eine Domain und
es kann einige Tage dauern, bis sie an alle DNS-Server im Internet weiter-
gegeben wird. Doch zu keiner Zeit ist ein bestimmter DNS-Server nicht er-
reichbar (solange Sie eine Verbindung mit ihm herstellen können).