[
https://issues.apache.org/jira/browse/HBASE-11288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17155797#comment-17155797
]
Francis Christopher Liu commented on HBASE-11288:
-------------------------------------------------
I think we are conflating the purpose of caching and that makes the evaluation
a bit confusing. Here's my attempt at fleshing them out. And drawing some
conclusions. There's essentially two cases:
# Caching to prevent master to become part of read/write path - this use case
is only presenet in "local master region". Caching here is used to reduce the
effect of disadvantage. Bad enough to be required as part of any serious
deployment(?).
# Caching to avoid hot regions. - this is something potentially optional in
"general root table". But arguably recommended in "local master region" given
the sharing of master and root responsibilities in a single process. There is
some nuance here as to why this caching use case is more important/recommended
for "local master region" because of being colocated with the master especially
when it comes to scaling(?).
For 2, I think we are special casing root a little too much. For example in
"general root table" implementation although splitting meta can reduce hot
regions and help with scaling it does not eliminate it. In fact in our
experience we run into hot meta regions more often than hot Root region. In
which case I believe if we are considering caching as a solution for hot root
region we need to think more holistically and think about a solution for
Catalog Tables as a whole. Along those lines, although it's currently not a big
deal for us, would it also make sense to consider availability for Catalog
Tables as whole, which also can potentially be addressed with caching? The same
can be said with the noisy neighbors argument does it really make sense to
special case root instead of coming up with a holistic solution for Catalog
Tables as a whole? It seems one potential advantage for "general root table" is
being able to address issues with the Catalog Tables holistically potentially
having a simpler and more elegant solution. The devil is in the details here of
course and so the general question is how important is special casing root for
any particular use case vs fixing it for catalog table as a whole. It at least
seemed to me based on discussions and the design doc that the 2-tier was
potentially that use case.
What do you guys think?
> 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)
