Using Riak as cache layer

Pavel Kogan pavel.kogan at cortica.com
Mon Oct 1 11:35:39 EDT 2012


Thanks Sean.

On Mon, Oct 1, 2012 at 4:48 PM, Sean Cribbs <sean at basho.com> wrote:

> Yes, it will drop the oldest item until the size is less than max_memory.
>
> On Mon, Oct 1, 2012 at 9:38 AM, Pavel Kogan <pavel.kogan at cortica.com>
> wrote:
> > Hi Sean,
> >
> > Thanks for quick reply. Your answers helped me a lot.
> > I just need small clarification.
> >
> > Memory backend has two parameters: (a) max_memory (b) ttl.
> > If I use only max_memory (without using ttl) and node reaches its
> > RAM limit would it drop oldest records upon new request as you said (or I
> > must set also ttl for that)?
> >
> > Thanks,
> >    Pavel
> >
> > On Mon, Oct 1, 2012 at 3:14 PM, Sean Cribbs <sean at basho.com> wrote:
> >>
> >> In contrast to Yuri's claim, a number of groups have used Riak
> >> successfully as a cache. Yes, it won't be as fast as Membase, but it
> >> might be fast enough for your purposes. (This presentation by
> >> Posterous might interest you:
> >>
> >>
> http://basho.com/blog/technical/2012/01/30/Riak-in-Production-at-Posterous-Riak-Control-Preview/
> )
> >>
> >> 1) Bitcask is going to be very fast. If your data never really exceeds
> >> RAM, Bitcask will give you near-RAM speeds with the assurance that
> >> your cache will also persist to disk.  Normal Bitcask caveats apply
> >> here, including the "keys-must-fit-in-RAM" one.
> >> 2) For most persistent use-cases it is recommended to have > 3 nodes,
> >> preferably 5 or more. For a cache, the guarantees of per-key
> >> availability are usually more lax, so perhaps < 3 nodes is ok. It's
> >> better to set up your desired configuration, run some benchmarks and
> >> smoke-tests while stopping or killing nodes.
> >> 3) If you are using the "memory" backend, you can configure this
> >> behavior. If you do not configure it, the default is to use up to as
> >> much memory as the operating system will allow it -- beyond that
> >> limit, the Riak node will exit and leave a crash dump. If you
> >> configure a size or TTL limit, then the memory backend will drop the
> >> oldest item from its storage.  More information on how to configure it
> >> is here: http://wiki.basho.com/Memory.html
> >>
> >> I hope that helps!
> >>
> >> On Mon, Oct 1, 2012 at 8:57 AM, Yuri Lukyanov <snaky at aboutecho.com>
> wrote:
> >> > I suggest that you use http://www.couchbase.com/ (ex-membase)
>  instead
> >> > as a cache layer. It's faster but less reliable than riak, which is ok
> >> > for cache layer.
> >> >
> >> > On Mon, Oct 1, 2012 at 12:47 AM, Pavel Kogan <pavel.kogan at cortica.com
> >
> >> > wrote:
> >> >> Hi all experts,
> >> >>
> >> >> I want to use Riak for caching and have few questions:
> >> >>
> >> >> 1) How faster is using memory back-end over bitcask back-end (on
> SSD)?
> >> >> 2) If throughput satisfying, is there any reason to use more than two
> >> >> nodes?
> >> >> 3) When my memory reaches preset limit (lets say 4Gb) what is going
> to
> >> >> happen
> >> >>     on inserting the next element?
> >> >>     a) Random element will be dropped.
> >> >>     b) Oldest element will be dropped.
> >> >>     c) Next element insert will fail.
> >> >>
> >> >> Thanks,
> >> >>    Pavel
> >> >>
> >> >> _______________________________________________
> >> >> riak-users mailing list
> >> >> riak-users at lists.basho.com
> >> >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
> >> >>
> >> >
> >> > _______________________________________________
> >> > riak-users mailing list
> >> > riak-users at lists.basho.com
> >> > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
> >>
> >>
> >>
> >> --
> >> Sean Cribbs <sean at basho.com>
> >> Software Engineer
> >> Basho Technologies, Inc.
> >> http://basho.com/
> >
> >
>
>
>
> --
> Sean Cribbs <sean at basho.com>
> Software Engineer
> Basho Technologies, Inc.
> http://basho.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20121001/75462f9f/attachment.html>


More information about the riak-users mailing list