wchevreuil commented on pull request #1883:
URL: https://github.com/apache/hbase/pull/1883#issuecomment-648309919
> IMO if we change split policy to consider region's total size rather than
HStore size, we should also correct the config name. We can follow deprecation
cycle for the config. But with current hregion.max.filesize its more confusing.
> Now this config make sense because after a major compaction all the files
under a Store will become single large file. So based on this max possible size
we decide the split (So we sum all file's size under a store).
I don't think changing the config name is strictly required. Official docs
are clear about the expected behaviour for hbase.hregion.max.filesize, and this
policy current violates that:
`hbase.hregion.max.filesize
Description
Maximum HFile size. If the sum of the sizes of a region’s HFiles has grown
to exceed this value, the region is split in two.`
This policy also breaks MAX_FILESIZE table descriptor expected behaviour, as
per ableDescriptorBuilder javadoc:
`Returns the maximum size upto which a region can grow to after which a
region split is triggered. The region size is represented by the size of
the biggest store file in that region.
`
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
