If what you say is true in the general case, it is probably advisable to add this as a feature. If one other person needed it, it would seem fine to just DIY. But it sounds like in general something users would want. If you could file an issue or even contribute some code that would be great.
-Tom On Thu, Apr 23, 2009 at 12:29 PM, Jonathan Gray <[email protected]> wrote: > Bob, > > In my experience, it does make sense to pool HTable instances. > > Internally we use something we call HBaseRef that does this for us. The > general API of it is just HBaseRef.getTable(String) and > HBaseRef.putTable(HTable). This was designed way back in 0.2.1 so might > be a bit overkill today. > > The two things to take in to account w.r.t. HTable: > > - Instantiating a new HTable is costly, often times an order of magnitude > or more slower than a single random read. This is really what we want to > avoid in a web-facing app w/ low latency requirements. > > - All testing and benchmarking has shown that there is no performance > difference for READS in different threads sharing a single HTable. WRITES > do benefit from using a unique HTable per thread. > > So in practice, you do want to pool/reuse HTable instances because you > want to keep latency low. Might be useful to actually make an HTablePool > as part of HBase client utilities. > > There's nothing complex about it, but if you are interested in seeing code > let me know and I can file an issue. > > JG > > On Thu, April 23, 2009 12:25 am, Bob Schulze wrote: >> Is Hbase' Connection manager already taking care of the connection >> pooling? Does it make sense to Pool HTable instances in a multi-threaded >> (web like) usage scenario? >> >> >> Thx, >> >> >> Bob >> >> >> > >
