Hi, HTable is a small shim on top of other infrastructure inside the client. We only open 1 socket per regionserver per JVM to talk to each regionserver, and all HTable instances share that. HTable instances also create a small ThreadPoolExecutor to help with parallelism. Thus the overhead of creating more HTables is not very high, but it is not entirely 0, hence why HTablePool exists.
The general guideline is that each thread requires their own HTable, since it's just a shim on top of HConnectionManager and friends, this requirement shouldn't be too onerous. -ryan On Wed, Nov 10, 2010 at 11:57 AM, tsuna <[email protected]> wrote: > On Tue, Nov 9, 2010 at 8:14 AM, Michael Segel <[email protected]> > 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 >
