bucket property description

[pawel-kaminski-krk]

bucket property description

[moreaki]

Why not add some examples, while we're at it? I found my information by skimming through some slides found on slideshare. For example:

http://www.slideshare.net/hemulen/introducing-riak (the information therein would make for a great documentation)
http://www.slideshare.net/seancribbs/introduction-to-riak-red-dirt-ruby-conf-training (starting from slide 122, for example).

In my notes, I have the following entries:

OBSERVATIONS:

One of the nice things with Riak it’s that it let you defined the N, R and W value for each operation. These values are:

N: the number of replicas of each value to store; objects are written to multiple partitions (default: 3)
R: the number of replicas required to perform a read operation or how many replicas need to agree (default: 2)
W: the number of replicas needed for a write operation, how many replicas to write before returning a successful response (default: 2)

This is also called the "Dynamo Quorums". The dynamo math is as follows:

N - R: read fault tolerance
N - W: write fault tolerance

Example: N = 4, R = 2, W = 2

N - R = 2 (nodes can be down and Riak can still perform READ's)
N - W = 2 (nodes that will receive hinted WRITE's)

R = W (read your write consistency)
R + W > N (strong consistency)

N can vary per bucket.
R, W can vary per operation.

Example:

PUT /riak/bucket 
Content-type: application/json
{"props":{"nval":5}}
  ==> bucket.n_value = 5

Request-time quorums (ruby-like syntax):

GET /riak/bucket/key?r=1
  ==> bucket.get('key', :r => 1)

PUT /riak/bucket/key?w=4
  ==> object.store('key', :w => 4)

Other quorums:

DW: Durable writes (stored to disk: how many replicas to commit to durable storage before returning a successful response, default: 0)
RW: quorum for deletes (delete is a write!, default: 0)

[danostrowski]

Adding an example for PW might be difficult so it might be good to link to an "advanced usage" area.

An example of when PW is relevant is in the face of network partitions. If you have a network partition, splitting out, say, a single node from your cluster, it's possible you could write to that node as usual and not know the difference. The node will produce fallback partitions and accepts writes, even, say, with a w=2 value.

There's many bad scenarios, here, but even in the face of locking on the client side, if a partition continues then you can either lose data (if using LWW strategy) or you can come up with siblings even if your operations were not conflicting.

Using PW, potentially, can prevent some of these problems by failing fast for the client letting it know "hey, I don't have enough real owners of this data piece to complete the operation." In many scenarios, this is desirable behavior, especially when writing non-CDRT or immutable data.

[macintux]

Issue #225 and its associated PR address much of this.

[lucperkins]

I think that this doc and several others adequately address this. Closing.

[danostrowski]

Where are things like PR and PW covered, just out of curiosity? Is there a page that goes over those?

[lucperkins]

These are very much under-documented. I'm working on that now, primarily in
a more comprehensive pull request #916. Those changes in particular haven't
yet been pushed, but I'm working right now on significantly improving the
docs on replication and conflict resolution.

For the time being, this blog post does a pretty good job of explaining:
http://basho.com/riaks-config-behaviors-part-2/. I'll be using it for help
in writing the new docs.

On Mon, Mar 17, 2014 at 7:57 PM, Dan Ostrowski [email protected]:

Where are things like PR and PW covered, just out of curiosity? Is there a
page that goes over those?

Reply to this email directly or view it on GitHubhttps://github.com//issues/10#issuecomment-37895103
.