hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Luo <j...@merkleinc.com>
Subject is it a good idea to disable tables not currently hot?
Date Thu, 17 Mar 2016 21:50:46 GMT
We have a multi tenants environment and each client occupies x number of hbase regions. We
currently have about 500 regions per region server and I understand the guideline is less
than 200. So we need to reduce the region counts. Increasing region file size is no more an
option because we are already at 5G and I don’t want to go higher.

Due to our unique use cases, all clients are running for a few hours in a day, then being
quiet for the rest of time. So I am thinking whether it is a good idea to disable all quiet
tables and only enable them when they are ready to run. Does anyone have experience on that?

One thing I worry about is the Balancer. I am pretty sure the balancer will be confused when
regions come and go. And I cannot afford not to have it running in case of region server crashes
and come back. So doesn’t anyone have good ideas how to handle it?

I already doing compact myself so that is not an issue.

Another related question, if a region is enabled but not active read/write, how much resources
it takes in terms of region server?


Frank Luo

Merkle was named a leader in Customer Insights Services Providers by Forrester Research

Forrester Research report names 500friends, a Merkle Company, a leader in customer Loyalty
Solutions for Midsize Organizations<http://www.merkleinc.com/who-we-are-customer-relationship-marketing-agency/awards-recognition/500friends-merkle-company-named?utm_source=emailfooter&utm_medium=email&utm_campaign=2016MonthlyEmployeeFooter>

This email and any attachments transmitted with it are intended for use by the intended recipient(s)
only. If you have received this email in error, please notify the sender immediately and then
delete it. If you are not the intended recipient, you must not keep, use, disclose, copy or
distribute this email without the author’s prior permission. We take precautions to minimize
the risk of transmitting software viruses, but we advise you to perform your own virus checks
on any attachment to this message. We cannot accept liability for any loss or damage caused
by software viruses. The information contained in this communication may be confidential and
may be subject to the attorney-client privilege.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message