Due to some reason, our riak cluster does not support multi-backend which
supports per bucket expiry.
so the TTL is per riak cluster now, TTL is 3 days, but I only need to keep
the keys for 6 hours for my bucket, I am deleting the old keys with a cron
job periodically.
Is there any other option
If you have much more short lived data than long lived data, tuning the
bitcask merge settings might help. Note that more frequent merging also
means more CPU and I/O usage.
I recently switched over to multi-backend exactly to deal with data in
different buckets having different life spans. The ma
As Alexander points out, the bitcask auto expiry feature [1] seems to fit
your use case. You should also have a look at your bitcask merge settings
[1] and your logs, to ensure merges are triggered when you want them to.
[1] http://docs.basho.com/riak/kv/2.0.6/configuring/backend/#bitcask
//Danie
Thanks for the information Alexander and Daniel, I appreciated it.
We are using Riak2.0 and bitcask as backend, and we are writing the keys
once into bucket, keep it for a few hours, then delete it, never update the
existing data.
On Wed, Apr 20, 2016 at 11:32 AM, Alexander Sicular
wrote:
> Hel
Check out bitcask TTL, expiry.
-Alexander
@siculars
http://siculars.posthaven.com
Sent from my iRotaryPhone
> On Apr 20, 2016, at 12:20, Shifeng Xiao wrote:
>
> Thanks for the information Alexander and Daniel, I appreciated it.
>
> We are using Riak2.0 and bitcask as backend, and we are wr
Hello Shifeng,
Riak uses Bitcask as its default data backend, it may also use leveldb
as a backend but must be configured to do so[0][1]. Both bitcask[2]
and leveldb[3] do not reclaim disk space immediately when a delete is
issued. Incidentally, neither do updates. Because Riak is
non-destructive,
Hi,
What riak version and what riak backend are you using? For leveldb you have
to take compaction into account, and for older bitcask versions there are
known issues with data not being properly deleted.
//Daniel
___
riak-users mailing list
riak-users@
