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. 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. It would be interesting to hear back from some of you if you try it out, or if you need help doing so. Kresten _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
