[ 
https://issues.apache.org/jira/browse/HBASE-11288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17192765#comment-17192765
 ] 

Francis Christopher Liu commented on HBASE-11288:
-------------------------------------------------

Apologies for the late reply [~zghao]. 

It seems our definition of specialization is different and one does not 
contradict the other. Using your definition of specialization (use cases 
storing data in “local master region”), in essence I agree it is not. I’ll try 
to be careful using the word as it seems to not help move the discussion 
forward. As a side note, I’m sure you thought of this but just wanted to chime 
in: in general I’d weigh storing data on the master vs other options as the 
master won’t scale horizontally among other reasons. Although I think that 
discussion would be case by case and better suited in their own jiras.   

In terms of simplicity, I think if you look at both from different perspectives 
either one can be seen as simpler than the other. Here’s two possible 
perspectives:

The “local master region”  in one perspective is simpler as it keeps the root 
logic in the master. 

The “root  table” approach from an operations point of view is simpler as it’s 
only change is basically adding 1 more region to the cluster (worst case 2-tier 
assignment). 

Allow me to elaborate on the previous statement. “Root table” is operationally 
simpler compared to “local master region” as the latter adds new 
failure/operational modes, adds master to read/write path, etc. Then if caching 
is introduced in “local master region” the implementation becomes less simpler 
and operationally (depending how you look at it) more complex (although a bit 
more scalable and robust). In contrast based on our experience the “root table” 
approach will not need caching (except possibly for extreme cases we haven’t 
run into) hence operationally the change remains to be just the addition of 1 
region, the root region. 

As for “assignment problems” I think we’ve proven through the successful ITBLL 
runs that hbase-2 is able to handle the extra tier of assignment? As for 
understanding the code the approach is mainly extending existing meta code not 
really adding new code paths. If a developer understands meta code they will 
easily be able to understand root code as it is merely an extension of the 
other. 

It would be great if we could come up with a solution that offers the 
simplicity of both. If not then it’d be great to come up with one that offers 
the best benefit factoring in any tradeoffs. I think this is where 
understanding different perspectives would be helpful.


> Splittable Meta
> ---------------
>
>                 Key: HBASE-11288
>                 URL: https://issues.apache.org/jira/browse/HBASE-11288
>             Project: HBase
>          Issue Type: Umbrella
>          Components: meta
>            Reporter: Francis Christopher Liu
>            Assignee: Francis Christopher Liu
>            Priority: Major
>         Attachments: jstack20200807_bad_rpc_priority.txt, root_priority.patch
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to