I meant to say that the read is eventually consistent and that does not affect durability.
-- Ahmed Al-Saadi Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Saturday, January 21, 2012 at 12:35 AM, Ahmed Al-Saadi wrote: > Would it then be accurate to rephrase your statement by saying that data > durability is guaranteed (specifically when dw>=1), but that reporting this > durability is not? > > -- > Ahmed Al-Saadi > Sent with Sparrow (http://www.sparrowmailapp.com/?sig) > > > On Friday, January 20, 2012 at 1:09 PM, Sean Cribbs wrote: > > > Be aware that the client quorums are only a restriction on what the client > > will wait for. It is entirely possible for a write to succeed in the larger > > case, but not meet the W/DW quorum requirements. That is, the request may > > "fail" but the write may still occur. > > > > On Fri, Jan 20, 2012 at 10:01 AM, Dmitry Demeshchuk <demeshc...@gmail.com > > (mailto:demeshc...@gmail.com)> wrote: > > > Generally, using eventually consistent databases for e-commerce sounds > > > too risky. > > > > > > But I know that there was some e-commerce stealth startup using Riak > > > for their needs (probably not for all the data though, I don't know > > > any details). Amazon uses Dynamo, which is quite similar to Riak. So > > > NoSQL can be used in this niche somehow. > > > > > > Also, intuitively, most of the consistency problems might be avoided > > > by setting all w/dw values to maximum (better set r to maximum too, of > > > course). > > > > > > The hardest task I see here is to organize transactions for the cases > > > like "we remove a product from database and we should alter all the > > > orders that contain this product". > > > > > > On Fri, Jan 20, 2012 at 5:43 PM, Ahmed Al-Saadi <thaterlang...@gmail.com > > > (mailto:thaterlang...@gmail.com)> wrote: > > > > Hello: > > > > > > > > After reviewing a few options in the NoSQL space, I am considering using > > > > Riak for an e-commerce platform. I gather that atomicity (transactions) > > > > is > > > > not supported while durability can be enforced per request (using dw=1 > > > > or, > > > > at least, w=<suitable value>?). In other words, for most non-critical > > > > reads/writes, r/w can be optimized for availability while critical > > > > writes > > > > must be committed to disk (or to "enough" nodes?), sacrificing > > > > availability > > > > in the process. > > > > > > > > Does this describe the state-of-affairs or am I missing something? > > > > > > > > -- > > > > Ahmed Al-Saadi > > > > Sent with Sparrow > > > > > > > > > > > > _______________________________________________ > > > > riak-users mailing list > > > > riak-users@lists.basho.com (mailto:riak-users@lists.basho.com) > > > > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > > > > > > > > > > > > > > > -- > > > Best regards, > > > Dmitry Demeshchuk > > > > > > _______________________________________________ > > > riak-users mailing list > > > riak-users@lists.basho.com (mailto:riak-users@lists.basho.com) > > > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > > > > > > > -- > > Sean Cribbs <s...@basho.com (mailto:s...@basho.com)> > > Software Engineer > > Basho Technologies, Inc. > > http://basho.com/ > > >
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
