[
https://issues.apache.org/jira/browse/HBASE-15073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103608#comment-15103608
]
stack commented on HBASE-15073:
-------------------------------
bq. In the above scenario, region split request during normalization doesn't
play as important a role as that for region merge.
Sure.
bq. Therefore user has the choice of turning off region split (during
normalization).
I don't follow. Would a split even be issued? The merge is keeping table
regions tidy. And then why would I want the 'choice' of turning off splits?
This is all an intellectual exercise, right? Any evidence from a running
cluster to backup need for finer grainer control?
Any other use cases other than this "If timeseries and if FIFO compaction and
if the user wants to turn off splits....."?
Users don't want choice. There is too much 'choice' in hbase already. They just
want hbase to make the right choice.
bq. I am open to suggestion on better encoding for these two operations.
I suggest just purging this pursuit of 'finer grained control' over
normalization and instead try and go the other direction where you turn
normalization on and it just does the right thing autonomously... then no need
of this 'MS' or 'S' or 'M'... stuff.
> 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)
