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