I would love to go with bitcask but its memory usage bloats over time as the number of keys goes up. My use case involves keys which keep on increasing over time. Bitcask seems to be maintaining an in mem structure of key locations.
So the quest for a backend which will have a steady memory footprint in presence of ever increasing keys. I have rigged up a tokyo cabinet backend using toke [ www.lshift.net/blog/2009/12/21/merry-christmas-toke-tokyo-cabinet-driver-for-erlang] and its working pretty ok, though I have not done a scientific study comparing both. Its pretty steady on its memory foot print which is my main concern. -- Jebu Ittiachen [email protected] On Fri, Jul 23, 2010 at 11:47 AM, Dmitry Demeshchuk <[email protected]>wrote: > Tokyo Cabinet seems bad compared to Bitcask: > > http://pl.atyp.us/wordpress/?p=2868 > > Do you really need it? > > On Fri, Jul 23, 2010 at 9:13 AM, Jebu Ittiachen <[email protected]> wrote: > > Hi, > > Has anybody tried out tokyo cabinet as a backend for riak? I have hit > > blockers with existing backends for my usage. Innostore has a key length > > limit of 255 chars and bitcask wants to hold all keys in memory. I have > been > > looking at an alternate which can handle a huge number of keys, tokyo > > cabinet seems to be ideal. Though I have not been able to find any > > references to usage of tokyo cabinet behind riak. > > -- > > Jebu Ittiachen > > http://inagist.com/ > > [email protected] > > @jebui > > _______________________________________________ > > riak-users mailing list > > [email protected] > > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > > > > > > > -- > Best regards, > Dmitry Demeshchuk >
_______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
