hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lin Ma <lin...@gmail.com>
Subject Re: Using HBase serving to replace memcached
Date Mon, 20 Aug 2012 16:09:00 GMT
Thank you Drew. I like your reply, especially blocking cache nature
provided by HBase. A quick question, for traditional memcached, all of the
items are in memory, no disk is used, correct?


On Mon, Aug 20, 2012 at 9:26 PM, Drew Dahlke <drew.dahlke@bronto.com> wrote:

> I'd say if the memcached model is working for you, stick with it.
> HBase (currently) caches whole blocks. With cache blocks enabled you
> can achieve 10s of thousands of reqs/sec with a pretty small cluster.
> However there's a catch. Once you reach the point where your tables
> are so large they can't all sit in memory at the same time you'll see
> a behavior change. User traffic tends to be very random access which,
> with block caching, can cause a lot of thrashing with frequent cache
> evictions. We've seen this bring our cluster to it's knees.
> IMHO a better model is persist things in HBase and then cache things
> with memcached just as you would with any other data store. If you're
> looking for a spiffy memcached replacement I'd recommend checking out
> Redis.
> On Sat, Aug 18, 2012 at 3:12 AM, Lin Ma <linlma@gmail.com> wrote:
> > Hello guys,
> >
> > In your experience, is it practical to use HBase directly for serving?
> > Saying handle directly user traffic (tens of thousands QPS scale) behind
> > Apache, and replace the role of memcached? I am not sure whether there
> are
> > any known panic to replace memcached by using HBase? One issue I could
> > think about is for a specific row range, only one active region server
> > could handle the request, but in memcached, we can setup several
> memcached
> > instance with duplicate content (all of them are active) to serve the
> same
> > purpose under a VIP which could achieve better performance and
> scalability.
> >
> > Any advice or reference documents are appreciated. Thanks.
> >
> > regards,
> > Lin

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message