Side question: dynamo exposes both partial and fully consistent reads. Does anyone know what the conflict semantics are? Last write wins? Actual mvcc?
Ahmed Al-Saadi <thaterlang...@gmail.com> wrote: >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 _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
