Mailing-List: contact user-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hbase.apache.org
Received-SPF: pass (nike.apache.org: domain of kevin.odell@cloudera.com
 designates 209.85.212.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CALCVZZtiv-hWxXOEk4g5BsCg-mKt2PoBT4FjNH0Lr6uSQZgJmA@mail.gmail.com>
References: 
 <CALCVZZtiv-hWxXOEk4g5BsCg-mKt2PoBT4FjNH0Lr6uSQZgJmA@mail.gmail.com>
Date: Fri, 24 Aug 2012 11:04:35 -0400
Message-ID: 
 <CAGngS9e-p7XiyfNU0xcKOwrvJJVn=08SSXW8Vps7Lqg7sFL+Sw@mail.gmail.com>
Subject: Re: restriction on the number of tables in hbase and its impact on
 performance
From: "Kevin O'dell" <kevin.odell@cloudera.com>
To: user@hbase.apache.org
Content-Type: multipart/alternative; boundary=047d7bdcacfc4cda9304c8044bae

--047d7bdcacfc4cda9304c8044bae
Content-Type: text/plain; charset=ISO-8859-1

Rohit,

  This is an interesting question, but it sounds like overkill.  I would
not worry about having tables up that aren't active.  If you keep your
active region count down and your memory footprint reasonable <16GB heap
you should be fine.

On Fri, Aug 24, 2012 at 1:01 AM, Rohit Kelkar <rohitkelkar@gmail.com> wrote:

> I have asked this question on stackoverflow -
>
> http://stackoverflow.com/questions/12066856/restriction-on-the-number-of-tables-in-hbase-and-its-impact-on-performance
>
> Also asking the same on this list --
>
> Our hbase schema in production has 5 tables. We have N clients where
> in only 10% of the clients are active at any given instant. So for me
> it looks like a waste of resources to keep the data of remaining 90%
> clients active. I was thinking of creating 5 tables per client so that
> I can keep the active client's tables enabled and the remaining
> client's tables disabled. From what I have read if we exceed 1000
> regions per region server then performance starts degrading. But I am
> sure not to hit that limit. My questions
>
> If I disable a set of tables then does it mean that I am putting less
> load on hbase?
> Does this seem like a sound strategy overall?
>
> - Rohit Kelkar
>


-- 
Kevin O'Dell
Customer Operations Engineer, Cloudera

--047d7bdcacfc4cda9304c8044bae--