StochasticLoadBalancer by default would balance regions evenly across the cluster.
Regions of particular table may not be evenly distributed. Increase the value for the following config: private static final String TABLE_SKEW_COST_KEY = "hbase.master.balancer.stochastic.tableSkewCost"; private static final float DEFAULT_TABLE_SKEW_COST = 35; You can set 500 or higher. FYI On Mon, Aug 29, 2016 at 3:22 PM, Manish Maheshwari <mylogi...@gmail.com> wrote: > Thanks Ted for the maxregionsize per table idea. We will try to keep it > around 1-2 Gigs and see how it goes. Will this also make sure that the > region migrates to another region server? Or do we still need to do that > manually? > > On JMX, Since the environment is production, we are yet unable to use jmx > for stats collection. But in dev we are trying it out. > > On Aug 30, 2016 1:01 AM, "Ted Yu" <yuzhih...@gmail.com> wrote: > > > bq. We cannot change the maxregionsize parameter > > > > The region size can be changed on per table basis: > > > > hbase> alter 't1', MAX_FILESIZE => '134217728' > > > > See the beginning of hbase-shell/src/main/ruby/shell/commands/alter.rb > for > > more details. > > > > FYI > > > > On Sun, Aug 28, 2016 at 10:44 PM, Manish Maheshwari <mylogi...@gmail.com > > > > wrote: > > > > > Hi, > > > > > > We have a scenario where HBase is used like a Key Value Database to map > > > Keys to Regions. We have over 5 Million Keys, but the table size is > less > > > than 7 GB. The read volume is pretty high - About 50x of the put/delete > > > volume. This causes hot spotting on the Data Node and the region is not > > > split. We cannot change the maxregionsize parameter as that will impact > > > other tables too. > > > > > > Our idea is to manually inspect the row key ranges and then split the > > > region manually and assign them to different region servers. We will > > > continue to then monitor the rows in one region to see if needs to be > > > split. > > > > > > Any experience of doing this on HBase. Is this a recommended approach? > > > > > > Thanks, > > > Manish > > > > > >