[
https://issues.apache.org/jira/browse/HBASE-25761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17364723#comment-17364723
]
Francis Christopher Liu commented on HBASE-25761:
-------------------------------------------------
{quote}
The difference comparing to a general root table and master local region here
is that, even we do not split meta, the root table and master local region is
there, most of the code will be executed. For example, the tiered assignment
and initialization.
{quote}
Yes and I think more importantly applying a different perspective there's new
operational complexity exposed to the operator (and possibly the user).
{quote}
In general, for me, the first meta as root solution is very like a compromise,
you need to do lots of magics in the row key and comparator, just like what I
have done in the master local region implementation, as we will also store
procedure data in the same region. But at least, the master local region will
use different families to store the data, so when reading we do not need to add
special filters...
{quote}
I see. From my perspective the difference in logic between _first meta region_
and _root table_ implementation is fairly straightforward, the composite
comparator has fairly simple logic, route based on presence/absence of prefix
character. For data access the key just needs to be prepended with the prefix
character, I haven't thought of a case yet wherein we'd need a specialized
filter (the rough PoC doesn't have one). The prefixing approach is also a
common end-user design pattern to achieve spatial locality for keys. Although
yes it would be a bit cleaner if the data would be in a separate hbase:root
table but I felt there's a good chance the community might see that (IMHO
small) difference a reasonable tradeoff for its compelling backward
compatibility characteristics. Hence it felt reasonable enough to include in
the discussion and hear what people think.
{quote}
And about the reviewing the implementing, trust me, no matter root table or
master local region, there are no big differences on the implementing steps.
{quote}
I see. I think there seems to be a significant difference between _first meta
region_ and _root table_ such that the former would be smoother (eg includes
the incremental disruption the steps produce) to get in wether it is a a big
difference across all three proposed solutions that I have not looked into.
Since you don't see any difference and this currently isn't a deciding factor
we don't really need to delve further unless needed.
> POC: hbase:meta,,1 as ROOT
> --------------------------
>
> Key: HBASE-25761
> URL: https://issues.apache.org/jira/browse/HBASE-25761
> Project: HBase
> Issue Type: Sub-task
> Reporter: Michael Stack
> Assignee: Francis Christopher Liu
> Priority: Major
>
> One of the proposals up in the split-meta design doc suggests a
> sleight-of-hand where the current hard-coded hbase:meta,,1 Region is
> leveraged to serve as first Region of a split hbase:meta but also does
> double-duty as 'ROOT'. This suggestion was put aside as a complicating
> recursion in chat but then Francis noticed on a re-read of the BigTable
> paper, that this is how they describe they do 'ROOT': "The root tablet is
> just the first tablet in the METADATA table, but is treated specially -- it
> is never split..."
> This issue is for playing around with this notion to see what the problems
> are so can do a better description of this approach here, in the design:
> https://docs.google.com/document/d/11ChsSb2LGrSzrSJz8pDCAw5IewmaMV0ZDN1LrMkAj4s/edit?ts=606c120f#heading=h.ikbhxlcthjle
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
