> If the database is in memory, why write it to bitcask? Seems like a > simple replay log is what you want in this situation. Because it's very handy to have KV over persistent copy :)
> Could this be an artifact of the large # of writes + deletes on the > file system? Nope. Each point there is 5 minutes away from each other, I don't think that file system artifacts can be so continuous. >Otherwise, I'm not quite sure what a good pattern would look like... Ideally as a straight line (I write the same amount of data each time, after all, I don't understand why it should take so different time to merge it). 2011/12/20 David Smith <diz...@basho.com>: > On Thu, Dec 15, 2011 at 10:51 AM, Dmitry Groshev <lambdadmi...@gmail.com> > wrote: >> I'm using standalone bitcask as a backend for our in-memory database >> (not opensourced yet). I write ~1.5GB of data to it each 5 minutes >> overwriting almost all keys and after that I run a merge as follows: > > If the database is in memory, why write it to bitcask? Seems like a > simple replay log is what you want in this situation. > > >> depicts a durations of merges; as one can see, there at least 2 "saw" >> forms with different time scales overlapped. Is there any reason why >> it is so? I have a gut feeling that such a variance isn't so good :) > > Could this be an artifact of the large # of writes + deletes on the > file system? Otherwise, I'm not quite sure what a good pattern would > look like... > > D. > > -- > Dave Smith > Director, Engineering > Basho Technologies, Inc. > diz...@basho.com _______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
