eventual consistency and events
jon at jbrisbin.com
Mon Feb 28 18:08:16 EST 2011
Correct me if I'm wrong but you write a high-performance app by specifying dw=all on every write. I'm thinking something along the lines of "take your time inserting the data, just let me know when you're finished". That's drastically different from "don't return from this call until you've written to every node I might potentially hit with a query".
Sent from my iPhone
On Feb 28, 2011, at 4:55 PM, Sean Cribbs <sean at basho.com> wrote:
> This is handled in Dynamo-style architectures like Riak with quorums. In Riak's case, you rely on the "W" and "DW" quorum values to determine what is an acceptable threshold for considering a write to be a success. By default, W and DW are set to "quorum", which means N/2+1 (for N=3, this is 2) partitions must reply that they both 1) received the write (W) and 2) committed the write to durable storage (DW). This allows you to lose one replica via outage, network partition, or overload and still have 2 copies available for read on the next operation. An interesting side-effect of this is that even though a write may appear to have failed from the client's perspective, some partitions may have succeeded.
> Sean Cribbs <sean at basho.com>
> Developer Advocate
> Basho Technologies, Inc.
> On Feb 28, 2011, at 5:47 PM, Jon Brisbin wrote:
>> In the midst of a discussion about messaging and eventual consistency and I'm wondering if there's a reasonable answer to the question:
>> Is eventual consistency in a system that needs to know when it can start querying the system for the just-inserted data not a problem if there is an event triggered when this checkpoint is reached (like a publisher acknowledgement) that tells the client "remember that data you inserted a few cycles back? It's ready to be queried now" and takes the place of a transaction?
>> The concern is that eventual consistency is bad when you need to know for sure that data was persisted to the store and the system currently uses transactions to ensure this.
>> Jon Brisbin
>> Twitter: @j_brisbin
>> riak-users mailing list
>> riak-users at lists.basho.com
More information about the riak-users