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
