If all primary nodes are up, the problem is nonexistent. You could
certainly implement any number of solutions inside Riak, but I cannot
see that there is 'one right way(tm)' to do it.
In such cases I am all in favor of providing all the needed primitives
to implement whatever is best for your application in a layer on top.
The ability to have a DELETE fail unless all primary nodes are up would
be one such primitive.
Am 16.06.2011 17:40, schrieb Greg Nelson:
Well, it is kind of Riak specific. An implementation that treated
DELETEs like PUTs (tombstones w/ vector clocks for ordering), then
this would not be an issue, right? When no primary nodes are down,
the tombstones can be physically deleted on the backend. A logical
delete could never reappear if that were how it worked.
Is this essentially what is on the current master branch (not yet
released)?
On Thursday, June 16, 2011 at 8:22 AM, Nico Meyer wrote:
The problem with unreachable nodes still remains, since you don't know
how long they will be gone. The only 'safe' minimum time to keep deleted
values is forever. This can be easily emulated in the application layer
by using a special value (or use Riak metadata for example).
So it essentially a trade off like most things. If you are sure that no
node will ever be down for more than 24 hours, your solution would work.
If it is really essential for an application that deleted keys don't
ever reappear, you should just store this information explicitly (that
way you also know when the key was deleted btw.). If not, then one can
live with the current behaviour, which is much simpler implementation
wise.
I would just separate the two issues of logically deleting and
physically deleting (which is just an operational issue as opposed to an
issue for your application design). The latter could be handled by the
storage backend. Bitcask already has a key expiration feature. If it
where fixed, so that expired key are actually counted towards the
triggering of merges, and the ttl could be set per key, you would be
good to go ;-).
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.
Cheers,
Nico
_______________________________________________
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
