Am 26.09.2012 23:20, schrieb Anthony Molinaro:
On Wed, Sep 26, 2012 at 10:04:54PM +0200, Kresten Krab Thorup wrote:
While we're discussing merge and expiry semantic here, I'd like to explain how
HanoiDB does it since that may be a reason for trying it out on your problem.
With the HanoiDB backend, merging and expiration is "incremental", which means
that log(N / #partitions) merge/expire operations are performed for every PUT or DELETE,
N being the total number og KVs stored in the backend.
Nothing more, nothing less. This means that you completely avoid the issue of
"having to schedule merging" at off-peak hours or some such. If you test it,
and your response times are satisfactory, then response times will continue being
satisfactory and predictably so.
What are the IOPS like for HanoiDB? I like bitcask because I know there will
only ever be one read, and as my operations are heavily weighted towards reads
I want to minimize them (even with SSD's we've found that too many reads can
cause poor latency).
We were thinking of switching to LevelDB, since the RAM requirements of
bitcask are starting to kill us, but the missing key expiration in
LevelDB is also a problem for us. So if HanoiDB sounds interesting. Has
it been tested in production sufficently, or would we be guinea pigs?
One "downside" of the current implementation is that if nothing is being
inserted (or deleted), then data doesn't expire (and disk usage isn't reduced), but that
may be a feature to add in the future.
Thats not a problem, at least for us. If you never insert anything, and
your disks aren't shrinking you should be fine, right ;-)?
While were at it, I might point out, that expiration should not be used
to invalidate old entries from the perspective of the application layer!
Since it is a storage backend only feature, if, for example, you loose a
node and replace it, read repair will recreate all keys on that node as
brand new, so they will only expire after whatever is your expiration
time. Same goes for node membership changes. Whats worse, the other,old
copies of a given key will expire much earlier, and if you read that key
afterward will be restored from the new copy by read repair, at which
point the roles of the old and new copies switch. This may go on ad
infinitum if you read often enough.
I've always wanted a way to control merging via riak-admin. We've been using
cassandra's control over compaction to schedule things for weekends off peak
and to make sure no 2 nodes are compacting at the same time. This sort of
thing is currently impossible with riak as the only controls you get are
either windows (but all nodes will have the same window unless you are
customizing config for every node, which is hard, and changing windows
requires restarts), or letting the merge triggers cause it to happen.
Having a way to fire it from the command line would allow you to manage
when it happens via cron or some other scheduling system which would
make for a more flexible setup IMHO.
Changing the merge_window in a running system is easy. Just 'riak
attach' and do the following:
application:set_env(bitcask, merge_window, always).
or
application:set_env(bitcask, merge_window, never).
But you can just use the attached skript to switch merging on/off from
any node ;-). Just make sure to adapt the first two lines to you
setting, especially you erlang cookie.
It would be interesting to hear back from some of you if you try it out, or if
you need help doing so.
If we have a chance we'll try it out, but as it's probably not a supported
backend for Riak EDS, we may not be able to. Any sense on if it will
make it into riak proper at some point?
-Anthony
--
Senior Backend Developer
________________________________________________
ADITION technologies AG
Schwarzwaldstrasse 78b
79117 Freiburg
http://www.adition.com
T +49 / (0)761 / 88147 - 30
F +49 / (0)761 / 88147 - 77
SUPPORT +49 / (0)1805 - ADITION
(Festnetzpreis 14 ct/min; Mobilfunkpreise maximal 42 ct/min)
Eingetragen beim Amtsgericht Düsseldorf unter HRB 54076
Vorstände: Andreas Kleiser, Jörg Klekamp, Tihomir Perkovic, Marcus Schlüter
Aufsichtsratsvorsitzender: Rechtsanwalt Daniel Raimer
UStIDNr.: DE 218 858 434
#!/usr/lib/riak/erts-5.8.5/bin/escript
%%! -name merge_switcher -setcookie COOKIE_GOES_HERE
main([NodeString, Command]) ->
NewSettingsValue =
case Command of
"enable" -> always;
"disable" -> never;
_ -> main([])
end,
Node = erlang:list_to_atom(NodeString),
{ok, State} = rpc:call(Node, application, get_env, [bitcask, merge_window]),
io:format("current state: ~p~n", [State]),
ok = rpc:call(Node, application, set_env, [bitcask, merge_window,
NewSettingsValue]),
io:format("switched to state: ~p~n", [NewSettingsValue]);
main(_) ->
io:format("~nUsage: riak_switch_merging nodename enable/disable~n"),
halt(1).
_______________________________________________
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
