I suppose this speaks to DynamoDB's consistent read feature that Vishal pointed out (though I believe statebox is more general). Thanks to both of you.
Your link helped me find the following insight from Bob Ippolito's blog: "[for an eventually consistent data store,] you have to move your conflict resolution from writes to reads." http://bob.pythonmac.org/archives/2011/03/17/statebox/ -- Ahmed Al-Saadi Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Friday, January 20, 2012 at 9:03 PM, Zheng Zhibin wrote: > > > Best regards, > Zheng Zhibin > > ÔÚ 2012-1-21£¬ÉÏÎç1:01£¬Dmitry Demeshchuk <demeshc...@gmail.com > (mailto:demeshc...@gmail.com)> дµÀ£º > > > 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". > > > > There is a lib which can help for this in some extent. > github.com/mochi/statebox (http://github.com/mochi/statebox) > > There is a Riak version as well: github.com/mochi/statebox_riak > (http://github.com/mochi/statebox_riak) > > Write for free, ops in read. > > > > 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 > > > > >
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
