Do you mean the write, not read? I have read about the theory of DynamoDB, it states that
"In a multiuser environment, how do you ensure data updates made by one client don't overwrite updates made by another client? The "lost update" is a classic database concurrency issue. Suppose two clients read the same item. Both clients get a copy of that item from Amazon DynamoDB. Client 1 then sends a request to update the item. Client 2 is not aware of any update. Later Client 2 sends its own request to update the item overwriting the update made by Client 1. Thus, the update made by Client 1 is lost. " Something is the counter-part to Riak's Vector Clock mechanism, but I think Vector Clock is much user-friendly mechanism and have better concurrent performance, since it is "accept all" and let user to handle the conflict later. As to the read operation: both are consistent, but one is eventually consistent(maybe miss out some recent writes), the other is consistent. 在 2012-1-21，下午5:11， Aphyr 写道： > 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
