eventual consistency and events
jon at jbrisbin.com
Tue Mar 1 08:27:53 EST 2011
So the coordinators could be made to hang around, replying on quorum and other events, then dispatching an event when everything's been updated? I assume the interested code would register an event hook on the bucket properties like a commit hook?
On Feb 28, 2011, at 5:10 PM, Sean Cribbs wrote:
> Ah, I misunderstood you. This would be an interesting addition to Riak, but is not in the current roadmap. The request coordinators currently reply and exit as soon as quorum is met, even if that's 0, so the replies from the vnodes never get delivered if the coordinator is gone.
> Sean Cribbs <sean at basho.com>
> Developer Advocate
> Basho Technologies, Inc.
> On Feb 28, 2011, at 6:08 PM, Jon Brisbin wrote:
>> 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