Lacking in considering the multiple families situation sounds like a BUG type to me, I vote for #3. And it should be back-ported to all active branches.
-------------------------- Best regards, R.C ________________________________________ From: Wellington Chevreuil <wellington.chevre...@gmail.com> Sent: 19 June 2020 18:34 To: dev Subject: [DISCUSS] IncreasingToUpperBoundRegionSplitPolicy can lead to unpredictable large regions size While going through the changes proposed on HBASE-24530, we observed IncreasingToUpperBoundRegionSplitPolicy compares hbase.hregion.max.filesize against individual stores within a region when deciding whether to split a region or not. For tables having multiple families, this can lead to regions much larger than what's defined by hbase.hregion.max.filesize. Current proposal on HBASE-24530 is to add an extra policy that actually compares the overall region size (combining all region stores sizes) against hbase.hregion.max.filesize, but I wonder if it really makes sense to keep a policy with current IncreasingToUpperBoundRegionSplitPolicy behaviour. Would like to hear folks opinions if we should take any of the below actions? 1) Leave IncreasingToUpperBoundRegionSplitPolicy as it is and just add the new policy proposed on HBASE-24530; 2) Make IncreasingToUpperBoundRegionSplitPolicy deprecated and remove it from master branch; 3) Change IncreasingToUpperBoundRegionSplitPolicy to actually implement the logic of the new policy proposed on HBASE-24530; My view is that the current IncreasingToUpperBoundRegionSplitPolicy behaviour is a bug, and I vote for #3.
