[
https://issues.apache.org/jira/browse/HBASE-25761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17363624#comment-17363624
]
Duo Zhang commented on HBASE-25761:
-----------------------------------
In general I do not see any advantages comapring to just introduce a root table
here...
You mentioned a lot about backward compatibility in the design doc, but if you
do not split hbase:meta, you just need to copy the location to zookeeper when
assigning meta to get backward compatibility, not a big deal...
The paper for bigtable is 15 years ago, I do not think 'bigtable choose this
design' itself is a strong reason for us to also choose this design. We need to
discuss the real gain here.
For me, I do not see any advantages here comparing to introducing a root table,
I can only see we need to add more magic in our code in the design doc.
Thanks.
> 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)
