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). > 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. 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. > 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 -- ------------------------------------------------------------------------ Anthony Molinaro <antho...@alumni.caltech.edu> _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
