Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # user >> restriction on the number of tables in hbase and its impact on performance


Copy link to this message
-
Re: restriction on the number of tables in hbase and its impact on performance
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 <[EMAIL PROTECTED]> 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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB