My current app.config bitcask section is looking like this:
%% Bitcask Config
{bitcask, [
{data_root, "/var/lib/riaksearch/bitcask" },
{dead_bytes_merge_trigger, 10242880 },
{dead_bytes_threshold, 5242880 },
{max_file_size, 80000000 },
{expiry_secs, 86400}
]},
- Steve
--
Steve Webb - Senior System Administrator for gnip.com
http://twitter.com/GnipWebb
On Mon, 13 Jun 2011, Justin Sheehy wrote:
Hi, Steve.
The key to your situation was in my earlier email:
One note that is relevant for your specific use: the expiry_secs
parameter will cause a given item to disappear from the client
API immediately after expiry, and to be cleaned if it is in a file
already being merged, but will not currently contribute toward
merge triggers or thresholds on its own if not otherwise "dead".
That is, bitcask wasn't originally designed around the expiry-centric
way of removing old data, and data that has simply expired (but not
actively been deleted) will not be counted as garbage toward
thresholds or triggers at this time. It will be cleaned up in a
merge, but will not contribute toward causing the merge in the first
place. In a use case where you only add items and never actually
delete anything, a merge will never be dynamically triggered.
It is plausible that we could add some expiry-statistics measurement
and triggering to bitcask, but today that's the state of things. You
could manually trigger merges, but that currently requires a bit of
Erlang.
I hope that this helps.
-Justin
_______________________________________________
riak-users mailing list
[email protected]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
