[ 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)