Database Reference
In-Depth Information
curl -X PUT http://localhost:8091/riak/animals/jean?w=0 \
-H "Content-Type: application/json"
-d '{"nickname" : "Jean", "breed" : "Border Collie"}' \
Trotz all dieser Möglichkeiten werden Sie üblicherweise bei den Standard-
werten bleiben, solange Sie keinen triftigen Grund haben, das nicht zu tun.
Bei Logs können Sie W=0 setzen und Sie können W=N und R=1 für selten zu
schreibende Daten verwenden, um ein extraschnelles Lesen zu ermöglichen.
Schreiben und dauerhaftes Schreiben
Wir haben Ihnen bisher etwas verheimlicht. Schreiboperationen sind bei Riak
nicht notwendigerweise dauerhaft, d. h., sie werden nicht sofort auf die Fest-
platte geschrieben. Auch wenn eine
Knoten-Schreiboperation
erfolgreich war,
kann es noch zu einem Fehler kommen, bei dem ein Knoten Daten verliert.
Selbst bei W=N können Server ausfallen und Daten verlieren. Eine Schrei-
boperation wird für einen Moment im Speicher gepuffert, bevor sie auf der
Platte gespeichert wird und dieser Bruchteil einer Millisekunde stellt eine
Gefahr dar.
Das sind schlechte Nachrichten. Die gute Nachricht lautet, dass Riak ei-
ne Einstellung namens DW für
durable write
, also „dauerhaftes Schreiben“
kennt. Das ist langsamer, aber reduziert noch einmal das Risiko, weil Riak
nicht zurückkehrt, bis das Objekt auf die Platten der angegebenen Anzahl
von Knoten geschrieben hat. Genau wie bei Schreiboperationen können Sie
diese Eigenschaft für ein Bucket festlegen. Nachfolgend setzen wir
dw
auf
one
,
um sicherzugehen, dass wenigstens ein Knoten die Daten gespeichert hat.
$
curl -X PUT http://localhost:8091/riak/animals
\
-H "Content-Type: application/json" \
-d '{"props":{"dw":"one"}}'
Wenn Sie wollen, können Sie das auch bei jeder Schreiboperation festlegen,
indem Sie den Query-Parameter
dw
in der URL nutzen.
Eine freundliche Warnung
Der Versuch, etwas an einen nicht verfügbaren Knoten zu schreiben, endet
immer noch mit einem „204 No Content“. Das liegt daran, dass Riak den Wert
an einen benachbarten Knoten schreibt, der die Daten vorhält, bis er sie an
den nicht verfügbaren Knoten übergeben kann. Das ist auf kurze Sicht ein
großartiges Sicherheitsnetz, weil ein anderer Riak-Knoten einspringt, wenn
ein Server unten ist. Wenn alle Requests für Server A nun aber an Server B
