Yes, you would get causal consistency with N=3, R=2, W=2. If client A, using some side channel, tells client B that it inserted something, it is guaranteed that client B can read it.
However, if you need to *update* data, causal consistency doesn't get you very far. Clients A and B can both read key X with value 1, and successfully update it to 2, and Riak will keep both values (or only the "newer one", depending on your settings). Then, when client C reads key X, it needs to figure out what to do with the multiple values it gets for key X. On Oct 31, 2011, at 22:57 , Justin Karneges wrote: > Oh, I didn't realize Riak had any client tracking. Does that work with the > HTTP interface too? > > If N=3, R=2, W=2, and client A writes something, how would client B not > immediately see the latest data? A won't get an acknowledgement until two > nodes are written to, and B would end up reading from at least one of those > nodes. > > On Monday, October 31, 2011 01:39:02 PM Sean Cribbs wrote: >> No, (P)R+(P)W > N guarantees that you read from an overlapping set of what >> you just wrote *from the same client*. It does not guarantee any kind of >> immediate consistency. However, what Riak *does* provide is some capacity >> for your data to approach consistency over time, through vector clocks, >> read-repair and hinted handoff. >> >> On Mon, Oct 31, 2011 at 4:20 PM, Justin Karneges <[email protected]> wrote: >>> As I understand it, if R + W > N then the DB is immediately consistent >>> rather >>> than eventually consistent, correct? Do the allow_mult and >>> last_write_wins settings have any effect when R + W > N? >>> >>> On Saturday, October 29, 2011 11:18:10 AM Reid Draper wrote: >>>> It sounds like your specific needs _might_ be possible with application >>>> logic, but be aware that Riak is an eventually consistent database. >>>> There are many subtleties to this type of coordination. You will need >>>> read-your-writes consistency, which means R + W > N. I would recommend >>> >>> the >>> >>>> following resources: >>>> >>>> http://wiki.basho.com/Eventual-Consistency.html >>>> http://www.allthingsdistributed.com/2008/12/eventually_consistent.html >>>> >>>> Terminology-wise, you should also know that there is no way to >>>> atomically update more than one replica (much less multiple keys) in >>>> Riak. This is >>> >>> one >>> >>>> of the tradeoffs for high availability in a distributed system. >>>> >>>> On Sat, Oct 29, 2011 at 1:46 PM, Jeremiah Peschka < >>>> >>>> [email protected]> wrote: >>>>> I'm just assuming that my implementation might be naive. >>>>> >>>>> As far as the tedious label goes, as your application's functionality >>>>> grows in complexity, you may find it tedious to manage the complexity >>> >>> of >>> >>>>> manually handling transactional rollback in a distributed system. >>>>> >>>>> Managing relationships using links has some maintenance overhead in >>> >>> Riak >>> >>>>> because of the nature of handling this sort of situation. >>>>> >>>>> But, all in all, it's probably not terrible as long as you decrease >>>>> the number of relationships in the application by saving related >>>>> objects within the same collection. >>>>> --- >>>>> Jeremiah Peschka - Founder, Brent Ozar PLF, LLC >>>>> Microsoft SQL Server MVP >>>>> >>>>> On Oct 29, 2011, at 10:32 AM, Justin Karneges wrote: >>>>>> On Saturday, October 29, 2011 08:42:52 AM Jeremiah Peschka wrote: >>>>>>> 1) Use an RDBMS. Since you're here, I'm guessing that you're >>>>>>> already >>>>> >>>>> using >>>>> >>>>>>> Riak or else that Riak has qualities that you want for your >>>>>>> application. >>>>>> >>>>>> Right. This is early on in the app's lifetime and the data storage >>> >>> is >>> >>>>> not >>>>> >>>>>> terribly complicated. I just need some parent/child relationships >>> >>> and >>> >>>>> when I >>>>> >>>>>> saw the Links feature I figured this was an expected usage of Riak. >>>>>> >>>>>>> 2) As Alex suggests, you can implement this in your application. >>>>>> >>>>>> Yes, this I am ready for. As I understand it, using Riak >>> >>> successfully >>> >>>>>> generally means designing your application with its limitations in >>>>>> mind. >>>>> >>>>> So, >>>>> >>>>>> let's go write some funky app code! >>>>>> >>>>>>> This could also be difficult: the application must be aware of >>>>>>> activity >>>>> >>>>> going >>>>> >>>>>>> on with objects in your database AND be able to roll them back. In >>>>>>> pseudocode you'd do this: >>>>>>> >>>>>>> orig = Riak.get('whatevs') >>>>>>> child = new Child(orig) >>>>>>> >>>>>>> >>>>>>> if Riak.put(child) >>>>>>> >>>>>>> if !Riak.link(orig, child) >>>>>>> >>>>>>> Riak.delete(child) >>>>>>> // error up the stack >>>>>>> >>>>>>> else >>>>>>> >>>>>>> // we don't care, the child didn't save. error up the stack >>>>>>> >>>>>>> This is probably naive and is definitely tedious, even if you do >>>>> >>>>> implement >>>>> >>>>>>> your own application layer to handle read/write operations. >>>>>> >>>>>> See, to me, this looks exactly like what you're supposed to do. >>>>>> How >>> >>> is >>> >>>>> it >>>>> >>>>>> naive and tedious? I would assume that everyone writing a serious >>> >>> app >>> >>>>> with >>>>> >>>>>> Riak has to do things like this. >>>>>> >>>>>> Justin >>>>>> >>>>>> _______________________________________________ >>>>>> riak-users mailing list >>>>>> [email protected] >>>>>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>>>> >>>>> _______________________________________________ >>>>> riak-users mailing list >>>>> [email protected] >>>>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>> >>> _______________________________________________ >>> riak-users mailing list >>> [email protected] >>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > _______________________________________________ > riak-users mailing list > [email protected] > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
