You're free to view the older revisions of this gist, but much of this content has been rewritten and will appear on the [Basho blog] (http://basho.com/blog) in the very near future.
Update: First part of the series is now at http://basho.com/understanding-riaks-configurable-behaviors-part-1/
I blew it: the section on
notfound_ok
is badly wrong. I'm not sure how to generalize the results, but here's what I found for the least optimal scenario.First: there's a key parameter called
FailureThreshold
which is used to terminate requests early. Ifnotfound_ok
is set to false, that comes into play when dealing with missing keys.The body values in this table indicate the value for the failure threshold based on true/false values for
basic_quorum
and theR
value for a request:basic_quorum
R=1
R=2
R=3
As Sean indicated, the key
R
value thatbasic_quorum
is designed to work with isR=1
. It's irrelevant for any otherR
value.To carry this analysis forward, let's assume we're asking 3 vnodes for a key, and the first 2 to respond do not have a value for that key, but the 3rd does.
This next table indicates the success vs. failure tallies accumulated by the FSM after each vnode responds;
notfound_ok
comes into play here, because setting that to true means that it's "ok" to get anotfound
response.notfound_ok
(So if we look at
notfound_ok=false
, after the 2nd vnode has replied with itsnotfound
, the current tally is 0 successes and 2 failures. It's not until we get to the 3rd vnode's response with a value for the requested key that we finally have a 1 in the success tally.)Now to decide at which point the client is informed of success or failure, and whether the client is informed of success or failure, we have to (I think) look at
enough/1
inriak_kv_get_core.erl
. Abbreviated a bit, its logic reads:In other words, as soon as the successful value is
>= R
or the failure value is>= FailThreshold
we'll stop waiting for responses and provide a response to the client.When we merge the data above into a table that indicates the number of vnodes that must respond before the client is informed of the results, we get interesting results.
If we want the value that's only present on the 3rd vnode, then, we have to wait for the response from all 3 vnodes, as highlighted below.
basic_quorum
notfound_ok
R=1
R=2
R=3
In other words, in this scenario, there are only 3 (really, 2) combinations of configuration values which will return the desired value to the client. (To be clear, all combinations will fix it via read repair after the request is completed.)
If we set
R=3
andnotfound_ok=true
, we'll always get the value.Alternatively, we can set
R=1
,basic_quorum=false
, andnotfound_ok=false
.Configuring the request to fail quickly rather than scan all vnodes unnecessarily is trivial: set
notfound_ok=true
, which is our default.