atomically updating multiple keys

Justin Karneges justin at affinix.com
Mon Oct 31 16:57:20 EDT 2011


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 <justin at affinix.com> 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 <
> > > 
> > > jeremiah.peschka at gmail.com> 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
> > > > > riak-users at lists.basho.com
> > > > > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
> > > > 
> > > > _______________________________________________
> > > > riak-users mailing list
> > > > riak-users at lists.basho.com
> > > > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
> > 
> > _______________________________________________
> > riak-users mailing list
> > riak-users at lists.basho.com
> > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com



More information about the riak-users mailing list