[
https://issues.apache.org/jira/browse/HBASE-15073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15105613#comment-15105613
]
Ted Yu commented on HBASE-15073:
--------------------------------
bq. why would I want the 'choice' of turning off splits?
The following description applies to time series data with FIFO compaction
policy enforced (used by Ambari Metrics Server).
If a region continues to receive write requests, ultimately it would split -
without intervention from normalizer.
On the other hand, if the region stops receiving new write request at some
point, its size would stabilize. After TTL passes for all the HFiles in the
region, FIFO compaction would make the region empty.
So there doesn't need to be split request sent from normalizer.
In fact, the split of regions not actively receiving writes increases the work
in the future because there would be merge request(s) when such regions become
empty after compaction policy kicks in.
I talked with an Ambari developer who is involved in development of Ambari
Metrics Server and verified the above observation.
bq. where you turn normalization on and it just does the right thing
autonomously
Letting region normalizer do the work autonomously is good but we're not there
yet.
This finer grained control allows various use cases benefit from region
normalizer given the current implementation.
Again, I am open to better naming of the normalization choices.
> Finer grained control over normalization actions for RegionNormalizer
> ---------------------------------------------------------------------
>
> Key: HBASE-15073
> URL: https://issues.apache.org/jira/browse/HBASE-15073
> Project: HBase
> Issue Type: Task
> Components: regionserver
> Reporter: Ted Yu
> Assignee: Ted Yu
> Fix For: 2.0.0, 1.2.0, 1.3.0
>
> Attachments: 15073-v1.txt, 15073-v2.txt, 15073-v2.txt, 15073-v3.txt,
> 15073-v4.txt, 15073-v5.txt
>
>
> Currently both region split and merge actions are carried out during
> normalization for underlying table.
> However, for certain use case(s), it would be desirable to perform only one
> type of action.
> There is one boolean flag, keyed by NORMALIZATION_ENABLED_KEY, per table that
> enables normalization.
> To provide finer grained control, we have several options:
> 1. introduce another per table flag to indicate which type(s) of actions are
> allowed ("N" for disabled, "S" for split only, "M" for merge only and "MS"
> for both split and merge)
> 2. introduce another global flag to indicate which type(s) of actions are
> allowed
> 3. modify the meaning of existing flag keyed by NORMALIZATION_ENABLED_KEY so
> that it indicates type(s) of actions
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
