[
https://issues.apache.org/jira/browse/HBASE-11288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17155573#comment-17155573
]
Michael Stack commented on HBASE-11288:
---------------------------------------
{quote}You mean that, with 'general root table', we will also only expose a
very simple API for locating meta?
{quote}
Yes. We could do this.
{quote}Client will not go to the root region directly but the cache on master
and backup master?
{quote}
Cache tier implementation is not part of this discussion unless you think it
needs to be. That the API locating ROOT content is simple and so easy to back
w/ a general cache is sufficient to our purposes here? Or do you think we need
to say more on this topic? (As to the cache implementation, I'd think we'd want
to avoid involving Masters in any caching solution if ROOT is located elsewhere
– involving Masters would undo a 'pro' of the 'general root table' direction as
you point out subsequently in your comment).
Your addition to the design doc seems good – I undid the bolded red (smile) –
but it seems we can't have this new addition and the point above it both stand
at the same time: revisit?
While extra-tier vs Master-in-line-for-meta-lookups are main pivot point
figuring where to locate ROOT, there are others like Master is writing an
in-process Region rather than remote RPC'ing and it'll have no 'noisy
neighbors'... I updated the design.
> 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)
