Database Reference
In-Depth Information
bank auch dann noch verfügbar bleibt, wenn mehrere Knoten ausfallen oder
aus anderen Gründen nicht reagieren.
Die Verteilung von Daten auf mehrere Server ist von Natur aus problema-
tisch. Soll Ihre Datenbank weiterlaufen, wenn sie vom Netzwerk getrennt
wird (d. h., wenn Nachrichten verloren gehen), müssen Sie einen Kompro-
miss eingehen. Sie können entweder für Server-Requests
verfügbar
bleiben
oder Requests ablehnen und die
Konsistenz
Ihrer Daten sicherstellen. Es ist
nicht möglich, eine verteilte Datenbank aufzubauen, die vollständig konsis-
tent, verfügbar und partitionstolerant ist. Sie können nur zwei Eigenschaften
garantieren (partitionstolerant und konsistent, partitionstolerant und ver-
fügbar oder konsistent und verfügbar, aber nicht verteilt). Das ist als CAP-
Theorem bekannt (Consistency, Availability, Partition tolerance). Details fin-
den Sie unter Anhang 2,
Das CAP-Theorem
, auf Seite 347, im Wesentlichen
handelt es sich aber um ein Problem im Systemdesign.
Doch das Theorem hat ein Schlupfloch. Tatsache ist, dass man nicht zu
je-
dem Zeitpunkt
konsistent, verfügbar und partitionstolerant sein kann. Riak
macht sich diese Tatsache zunutze. Es erlaubt Ihnen, Request-bezogen Ver-
fügbarkeit gegen Konsistenz einzutauschen. Wir wollen uns zuerst ansehen,
wie Riak seine Server clustert, und zeigen dann, wie man Lese- und Schreib-
operationen im Cluster abstimmt.
Der Riak-Ring
Riak teilt seine Server in Partitionen auf, die mit einer 160-Bit-Zahl (2^160)
gekennzeichnet sind. Das Riak-Team stellt diesen großen Integerwert gerne
in Form eines Kreises dar, den sie den
Ring
nennen. Wird ein Schlüssel einer
Partition zugeordnet, hilft der Ring dabei festzulegen, welche Riak-Server den
Wert speichern.
Eine der ersten Entscheidungen, die wir beim Aufsetzen eines Riak-Clusters
treffen müssen, besteht darin, die Anzahl der Partitionen festzulegen. Neh-
men wir an, Sie haben 64 Partitionen (Riaks Standardwert). Wenn Sie diese
64 Partitionen auf drei Knoten (Server) verteilen, weist Riak jedem Knoten
21 oder 22 Partitionen zu (64 / 3). Jede Partition wird als virtueller Kno-
ten bezeichnet, kurz
vnode
. Beim Booten gehen alle Riak-Services den Ring
durch und beanspruchen nacheinander Partitionen, bis alle vnodes zuge-
wiesen wurden (siehe Abbildung 8,
“Der Riak-Ring” mit 64 vnodes, verteilt
auf drei physikalische Knoten
, auf Seite 81).
Node A verwaltet die vnodes 1, 4, 7, 10...63. Diese vnodes werden auf Par-
titionen im 160-Bit-Ring abgebildet. Wenn Sie sich den Status der drei Ent-
wicklungs-Server ansehen (erinnern Sie sich an das
curl -H "Accept: text/
