hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tsuna <tsuna...@gmail.com>
Subject Re: Is HTable threadsafe and cachable?
Date Mon, 04 Apr 2011 17:24:47 GMT
On Mon, Apr 4, 2011 at 12:45 AM, Ashish Shinde <ashish@strandls.com> wrote:
> We are using hbase to power a web application. The current
> implementation of the data access classes maintain a static HTable
> instance to read and write. The reason being getting hold of HTable
> instance looks costly.
> In this scenario the HTable instances could more or less be perpetually
> cached. Is it reasonable to assume that HTables do not have some
> inherent timeout and are threadsafe across gets and puts?

Hi Ashish,
if you're interested in a thread-safe, scalable HBase client, take a
look at asynchbase: https://github.com/stumbleupon/asynchbase
It was designed from the ground up to be thread-safe, you only need
one instance of HBaseClient per cluster, regardless of how many tables
you're going to interact with.  It also greatly outperforms HTable,
especially in write-heavy workloads, because it uses far fewer threads
and has less lock contention.

Benoit "tsuna" Sigoure
Software Engineer @ www.StumbleUpon.com

View raw message