hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Segel <michael_se...@hotmail.com>
Subject RE: Why and When to use HTablePool?
Date Thu, 11 Nov 2010 00:14:37 GMT

> From: tsunanet@gmail.com
> Date: Wed, 10 Nov 2010 11:57:56 -0800
> Subject: Re: Why and When to use HTablePool?
> To: user@hbase.apache.org
> On Tue, Nov 9, 2010 at 8:14 AM, Michael Segel <michael_segel@hotmail.com> wrote:
> > The use case for the HTablePool is pretty much the same as any application where
you need to fetch a resource from a pool rather than constantly instantiate them.
> >
> > Really the driving factor on which to use (HTable or HTablePool) is going to be
your use case, or rather what it is you hope to achieve.
> HTable isn't thread-safe when you write to HBase.  I think that's why
> HTablePool exists.
> If you want a highly scalable HBase client in which you don't need to
> think about pools or thread safety, you can take a look at asynchbase:
> http://github.com/stumbleupon/asynchbase
> -- 
> Benoit "tsuna" Sigoure
> Software Engineer @ www.StumbleUpon.com

You really don't want to do multi-threading within a m/r job.

I mean, yes you can, but you don't really want to do it unless you have a really good reason.

But to your point, HBase can be used outside of a m/r job which is what I was talking about
in the paragraph you cut from my post.
There where you have a multi-threaded client, you'd want to use the HTablePool. 

And again, the driving factor will be your use case... even in a multi-threaded client, you
could still use HTable, albeit you need to make sure that you instantiate an instance within
the thread. 
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message