On Thu, Jun 16, 2011 at 9:49 AM, Les Mikesell <lesmikes...@gmail.com> wrote:
> On 6/16/2011 10:22 AM, Nico Meyer wrote: > >> >> > > > Btw, this whole issue is not really Riak specific. It is essentially a >> consequence of eventual consistency, where you have to make a trade off >> between the amount of bookkeeping information you want to store and the >> maximum amount of time (or number of updates) any part of the system can >> diverge from the rest of the system before you get undesired results. >> > > The 'eventual consistency' description makes you think the system will > eventually fix itself, though. But, won't you have a similar scenario - and > even more difficult to fix - where for one reason or another you need to > restore a backed up bitcask file that contains items deleted after the time > the backup was done? > Consistency doesn't have to be "correct". It absolutely is consistent for a deleted key on one node in a replica, to replicate itself even if it was purposefully deleted from the other N-1 nodes. It just means something is consistent. Raising awareness to the issues of key deletes and how they might be restored in the system is very important for a designer of applications for eventually consistent systems. Dave > > -- > Les Mikesell > lesmikes...@gmail.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
