Q: What mechanism does Riak have to deal with the unique user issue?
sean at basho.com
Fri Jul 9 21:07:34 EDT 2010
Carbon-copying to riak-users since this is an important discussion.
You seem to have a fundamental misunderstanding about how quorums work. Write quorums (W and DW) aren't guarantees of atomicity and [global] consistency, but of durability. There's no distributed transaction, two-phase commit, or mutual coordination of writes, simply an acknowledgment that the write was received on an adequate number of nodes.
One unintuitive side-effect of these "sloppy quorums" is that a write may appear to fail to the client (i.e. not meet quorum), but actually succeed on some number of nodes within the cluster. However, on the next read, if the nodes that did succeed report in a timely fashion, the previously failed nodes will be updated with the new value (read repair).
I tried to place strong caveats on the use of the If-None-Match header and read-before-write strategy because they can only be implemented on the client-side, and they only are able to present an asynchronously aggregated state at the time of request, not a strong guarantee of global consistency. Again, buyer beware.
Sean Cribbs <sean at basho.com>
Basho Technologies, Inc.
On Jul 9, 2010, at 7:17 PM, Carl Humphrey wrote:
> Hi Sean,
> regarding the answer to this question, i'm a bit confused with the answer.
> couldn't I choose to forgo availability ( for some of the cluster users ) and only create a new user when a majority vote write passes
> for instance
> i have 3 servers each connected to each other
> if 1 server gets cut off from the other 2 , it couldn't get a majority vote on a write and therefore cant add new users
> however the other side of the split brain could get a majority vote ( 2 out of 3 ) and therefore its safe to write. ( with the?If-None_Match header? )
> is this not the way the CAP settings work in riak work?
> if i want to be able to dish out unique resources to customer do i have to implement zookeeper alongside riak to do it?
> Much Thanks
> Q: What mechanism does Riak have to deal with the unique user issue?
> Riak has neither write locks nor transactions. There is no way to absolutely guarantee uniqueness without introducing an intermediary that acts as a single-arbiter (and point-of-failure). However, in cases when you aren't experiencing high write-concurrency on the data in question there are a few things you can do to simulate the uniqueness constraint:
> Check for existence of the key before writing. In HTTP, this is as simple as a HEAD request. If the response is 404 Not Found, the object probably doesn't exist.
> Use a conditional PUT (in HTTP) when creating the object. The If-None-Match: *header should prevent you from blindly overwriting an existing key.
> Neither of these solutions are bullet-proof because all operations happen in Riak asynchronously. Remember that it's eventually consistent, meaning that not all parts of the system may agree at all times, but they will converge on a single state over time. There will be corner-cases where a key doesn't exist when you check for it, the write via the conditional request succeeds, and you still end up creating an object in conflict. Caveat emptor.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the riak-users