Created
October 15, 2010 17:30
-
-
Save PharkMillups/628585 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
7:54 <tsal> where did the `ring` notion come from | |
07:54 <tsal> is that related to the consistent hashing | |
07:55 <bingeldac> yes | |
07:55 <bingeldac> http://wiki.basho.com/display/RIAK/Replication | |
07:56 <tsal> thanks, think someone may have linked that when I asked a similar question | |
yesterday, but I missed to bookmark it | |
07:57 <tsal> what is the significance (if I may be so naieve) of the R value… it seems that setting | |
n=3 and r=3 makes sense, but if you lose a node, and r=3 -- the read would fail… why | |
not read from one of the other two ? | |
07:58 <tsal> … or… is that somehow to ensure integrity ? | |
07:59 <tsal> although, I recognise you can reduce the R value on reads - it doesn't | |
*really* make sense (at least day #1 reading about Riak) to have a read fail because of this | |
condition - or is it expected to make reads with R=1 ? | |
07:59 <seancribbs> tsal: R is simply how many replicas will be waited for before replying | |
08:00 <seancribbs> R=N is generally not a good idea because it will return "not found" | |
responses when you have node failure | |
08:00 <johnae> so, basically a low R-value means faster response? why not just go with 1 then? | |
08:00 <seancribbs> not necessarily faster | |
08:01 <seancribbs> depending on the churn, R=1 may give you stale data more | |
than a higher R value | |
08:01 <bingeldac> depends on the tradeoffs your app has | |
08:01 <seancribbs> right | |
08:01 <johnae> yeah ok, if an updated value hasnt replicated yet? | |
08:02 <seancribbs> johnae: right, or that replica just came back after a partition | |
08:02 <johnae> ok good to know, I think we might actually have use for R=1 since some of | |
our data will just be put in ONCE and never updated | |
08:02 <seancribbs> for most applications, N/2+1 (aka "quorum") is a good value for R | |
08:03 <seancribbs> johnae: it's also good to know about "basic quorum" | |
08:03 <seancribbs> which is a special case for "not found" responses | |
08:03 <johnae> ok... | |
08:03 <seancribbs> basically it returns not-found sooner, rather than waiting for the last | |
replica to reply | |
08:04 <seancribbs> i.e. if you get N/2+1 not-found responses, not-found will be | |
returned to the client | |
08:04 <seancribbs> however, you don't generally hit that unless R=1 | |
08:05 <seancribbs> or R =< N - (N/2+1) | |
08:05 <seancribbs> so, for N=5, R=2 would invoke basic quorum for not-founds | |
08:06 <seancribbs> etc | |
08:06 <johnae> ok | |
08:08 <tsal> thanks dudes ^ and great to see I inspired a bit of a chat about it | |
08:09 <tsal> so for example if you have n=3 and r=3 – you effectively wait for all | |
three to agree what is most recent, which might involve waiting for replication of | |
that key to finish | |
08:09 <seancribbs> tsal: no, it only waits for the _type_ of response | |
08:09 <tsal> ah, ok | |
08:09 <seancribbs> if all come back "ok, here's the object" | |
08:10 <seancribbs> then R is satisfied | |
08:10 <seancribbs> once it has all the responses, the object is resolved to the latest | |
via the vector clock | |
08:10 dizzyd joined | |
08:10 <tsal> I just had a wtf moment with that last thing you just said, maybe | |
I need more manual :-D | |
08:11 <seancribbs> tsal: think of the vector-clock like a "family tree" for the object | |
08:11 <seancribbs> you can compare them and see which version is the latest | |
08:11 <tsal> ok… so … ah | |
08:11 <tsal> ok, interesting | |
08:12 <seancribbs> or you could think of them like a git commit log, if that helps | |
08:12 <tsal> somehow :) | |
08:13 <tsal> thanks again seancribbs | |
08:14 <seancribbs> np. a lot of this is on the wiki, btw. | |
08:15 <tsal> yeah, it's a little much to digest, when I have no clue about | |
this sort of thing | |
08:16 uberjar joined | |
08:17 nanoyak joined | |
08:18 <uberjar> congrats on the release! | |
08:19 <seancribbs> tsal: most of the time you need not worry about it | |
08:19 <seancribbs> but it's nice to understand | |
08:20 <tsal> :) yeah, naturally - I tried to watch the talk from nosql last year - | |
08:21 <tsal> lots of stuff in the first 5 mins I didn't understand… but the PAC -- "pick two" | |
approach you guys | |
took, which is a strength relates directly to this model of hashing and replication |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment