Tokyo Cabinet backend

Jebu Ittiachen jebu at jebu.net
Fri Jul 23 03:07:21 EDT 2010


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
jebu at jebu.net


On Fri, Jul 23, 2010 at 11:47 AM, Dmitry Demeshchuk <demeshchuk at gmail.com>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 <jebu at jebu.net> 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/
> > jebu at jebu.net
> > @jebui
> > _______________________________________________
> > riak-users mailing list
> > riak-users at lists.basho.com
> > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
> >
> >
>
>
>
> --
> Best regards,
> Dmitry Demeshchuk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20100723/5a2d7ccc/attachment.html>


More information about the riak-users mailing list