Vicky,
Riak is very careful about deletes and will not completely reap existing
values until several conditions occur. So instead of deleting the value
immediately -- because in a distributed system, race-conditions can occur
and you need to determine causal ordering of events -- Riak will write a
"tombstone" for the deleted key, which is simply a dummy value that tells
it "this was deleted" the next time the key was accessed. At a later time,
that tombstone can be cleaned up. Note that this is a *Riak* tombstone, its
storage backends know nothing of the semantics of this value and will
simply store it as the latest version of the item under the same key. So
what you are likely witnessing is that the tombstones have not yet been
reaped from the backend store (probably Bitcask given the memory usage) and
so they are consuming memory in the LUT ("keydir" in Bitcask's terminology).
On Wed, Jan 4, 2012 at 8:03 AM, Vicky Khanna <vicky.kha...@position2.com>wrote:
> Hi, ****
>
> ** **
>
> I had around 100 million entries in the riak cluster of 4 which was taking
> 9*4 = 36 GB of RAM.****
>
> I deleted some 40 million keys from the cluster and still the size is same.
> ****
>
> I restarted the cluster and still size is same.****
>
> Can anyone please tell why riak is still retaining its original size even
> after deletion.****
>
> ** **
>
> Thanks in Advance****
>
> ** **
>
> Vicky Khanna****
>
> ** **
>
> _______________________________________________
> riak-users mailing list
> riak-users@lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>
>
--
Sean Cribbs <s...@basho.com>
Software Engineer
Basho Technologies, Inc.
http://basho.com/
_______________________________________________
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
