[
https://issues.apache.org/jira/browse/HBASE-11288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17154103#comment-17154103
]
Francis Christopher Liu commented on HBASE-11288:
-------------------------------------------------
Thanks for you response Duo. So it sounds to me the main reason for going with
the “Root table on master” implementation is because of the strong disagreement
towards the “General Root Table” implementation in particular the fact that it
adds another tier in assignment. Given that “General Root Table” has proven
itself in BigTable and other clones (eg Accumulo AFAIK). The concern it seems
is specific to HBase’s implementation, there is a strong concern that we might
fail again at getting it to work. Correct me if I’m wrong here.
Regardless of which implementation the addition of split meta will not only be
a significant change to HBase but also something that we will likely be living
with for quite a while. Because of that I am proposing that we apply some rigor
on deciding which implementation we will go with.
My current thinking is given that the main reason it seems for picking “Root
table on master” is because we want to avoid failing at tiering again, why
don’t we come up with a way to validate that assertion? IMHO the situation now
and then are very different especially with the addition of ProcV2 and the
revamped Assignment. For validation, my understanding is we use ITBLL to test
wether the current 1-tier assignment is working properly or not, why don’t we
try and run ITBLL on the “General Root Table” POC to investigate and validate
the 2-tier assignment concern? Thoughts?
> 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
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
