[
https://issues.apache.org/jira/browse/HBASE-11288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17154247#comment-17154247
]
Francis Christopher Liu commented on HBASE-11288:
-------------------------------------------------
{quote}
Bigtable is designed way back in 2006, not everything in BigTable is correct.
And they do not give us their code so we do not know their framework on how to
deal with tablet assignment and tablet server crash.
{quote}
Yes of course my point was that it is not an unsolvable problem. It's unclear
wether you agree or disagree?
{quote}
What we have for now is procedure v2 in HBase, so our discussion should based
on procedure v2.
{quote}
Great we're on the same page then.
{quote}
And this is not only about adding another tier, how do you plan to distribute
the load of the general root table? Region replica is not stable enough, for
years.
{quote}
Let's follow Stack's previous comment? Let's not discuss replicas or caching as
they could be applied to either split meta implementation. Let's focus on the
tiering issue?
{quote}
This suggestion is weak. I'm afraid after running ITBLL we will sit here again
to argue that, 'This is only a POC, do not focus on polishing'.
{quote}
I'm missing something. It is a POC and its intent was to gather information and
help answer critical questions like this. So I'm not sure what the concern is
against POCs doing what POCs are supposed to be used for? Rest assured for this
particular case I am more concerned as to how we came to the decision than the
actual decision. It would be best for everyone if we could apply some rigor
for something so important.
{quote}
But from my understanding, ITBLL is for polishing. We should have a clear
design, and a clean code, and then we use ITBLL to find out the corner cases to
polish our code, make it more robust.
{quote}
It is definitely good for that. But what prevents us from using it for this
purpose? Wether it always passes, fails sometimes or fail always we learn
something and that is valuable for determining wether proc v2 can support
2-tier now, short term, long term or never. Then we can come to an informed
decision. For example we might decide we cannot wait that long for proc v2 to
mature so we go with 1-tier.
{quote}
And I want to know you opinion on 'master local region'. I've explain that,
with caching servers, master will not be on the critical path of normal client
read/write. Client just go to the cache servers, which is similar to read
replicas feature, but much easier to implement and more stable. Are there any
other concerns about this solution?
{quote}
It does help but it is still making a compromise to avoid the concerns of
2-tier. Which is why my main concern now is applying some rigor to help us come
to a well informed decision as to wether proc v2 cannot support it and we
should go with 1-tier. I think proc v2 is what was missing that prevented us
from succeeding in the past although it’s possible it may not be mature enough
at this stage.
> 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)
