[jira] [Comment Edited] (HBASE-25761) POC: hbase:meta,,1 as ROOT
[
https://issues.apache.org/jira/browse/HBASE-25761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364071#comment-17364071
]
Francis Christopher Liu edited comment on HBASE-25761 at 6/16/21, 5:41 AM:
---
{quote}
If we do not split, it just perform like before, so for most cases where meta
is not too large, we can not test the new code. It is easy to finally lead the
feature to die as the most easy way to fix the problem is to not split meta...
We have purged several features in the past already...
{quote}
I see, reasonable concerns from a testing and feature adoption perspective. The
thought was to be backward compatible and have split meta off by default to be
rolling upgradeable from 2.x to 3.x as defined in the requirements section of
the [design
doc|https://docs.google.com/document/d/11ChsSb2LGrSzrSJz8pDCAw5IewmaMV0ZDN1LrMkAj4s/edit?ts=606c120f#heading=h.hlxgjlyq79ge].
If there is such a switch then we could also use that switch to split the
original first meta region (having a total of 2 meta regions) when it is turned
on. And for testing perhaps we could turn it on by default or turn it on in
cases that need it? Removing the switch would then end support for single meta
case.
{quote}
And for reviewing and checking in, I do not think it is a big deal, I've been
implementing almost the whole feature on a feature branch already, not very
hard to do it step by step.
{quote}
I see in this case you are comparing it against the
[master-local|https://docs.google.com/document/d/11ChsSb2LGrSzrSJz8pDCAw5IewmaMV0ZDN1LrMkAj4s/edit?ts=606c120f#heading=h.djjy98rqkyig]
implementation and not the [hbase:root
table|https://docs.google.com/document/d/11ChsSb2LGrSzrSJz8pDCAw5IewmaMV0ZDN1LrMkAj4s/edit?ts=606c120f#heading=h.9lp7l2j5mefg]
one.
was (Author: toffer):
{quote}
If we do not split, it just perform like before, so for most cases where meta
is not too large, we can not test the new code. It is easy to finally lead the
feature to die as the most easy way to fix the problem is to not split meta...
We have purged several features in the past already...
{quote}
I see, reasonable concerns from a testing and feature adoption perspective. The
thought was to be backward compatible and have split meta off by default to be
rolling upgradeable from 2.x to 3.x as defined in the [requirements
doc|https://docs.google.com/document/d/11ChsSb2LGrSzrSJz8pDCAw5IewmaMV0ZDN1LrMkAj4s/edit?ts=606c120f#heading=h.hlxgjlyq79ge].
If there is such a switch then we could also use that switch to split the
original first meta region (having a total of 2 meta regions) when it is turned
on. And for testing perhaps we could turn it on by default or turn it on in
cases that need it? Removing the switch would then end support for single meta.
{quote}
And for reviewing and checking in, I do not think it is a big deal, I've been
implementing almost the whole feature on a feature branch already, not very
hard to do it step by step.
{quote}
I see in this case you are comparing it against the
[master-local|https://docs.google.com/document/d/11ChsSb2LGrSzrSJz8pDCAw5IewmaMV0ZDN1LrMkAj4s/edit?ts=606c120f#heading=h.djjy98rqkyig]
implementation and not the [hbase:root
table|https://docs.google.com/document/d/11ChsSb2LGrSzrSJz8pDCAw5IewmaMV0ZDN1LrMkAj4s/edit?ts=606c120f#heading=h.9lp7l2j5mefg]
one.
> 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)
[jira] [Comment Edited] (HBASE-25761) POC: hbase:meta,,1 as ROOT
[ https://issues.apache.org/jira/browse/HBASE-25761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364035#comment-17364035 ] Francis Christopher Liu edited comment on HBASE-25761 at 6/16/21, 3:30 AM: --- Thanks for your comment [~zhangduo]. >From what I can gather from the rough PoC that I did was that the salient >difference between this implementation and the root table implementation is >around the theme of backward compatibility. Some of which might seem valuable >to the community hence I wonder what the community thinks: # The compatibility code is built-in as part of the core implementation there is no extra code to support backward compatibility # It introduces no new major artifacts, such that: #* If hbase:meta region is not split it operationally will behave pretty much exactly the same way as before (no operator changes, user changes, etc). As opposed to having to be aware of the new hbase:root region from the get go. #* If hbase:meta region is split. Users/Operators only have to worry about hbase:meta regions (which one would have to in any split meta implementation), no new hbase:root table to worry about. Although yes one would need to be aware of the first meta region getting assigned first. # I think it might also be smoother to get reviewed and checked in #* Intuitively given 1 & 2, I think it might be easier to add things more piece meal vs root table was (Author: toffer): Thanks for your comment [~zhangduo]. >From what I can gather from the rough PoC that I did was that the salient >difference between this implementation and the root table implementation is >around the theme of backward compatibility. Some of which might seem valuable >to the community hence I wonder what the community thinks: 1. The compatibility code is built-in as part of the core implementation there is no extra code to support backward compatibility 2. It introduces no new major artifacts, such that: 2.a If hbase:meta region is not split it operationally will behave pretty much exactly the same way as before (no operator changes, user changes, etc). As opposed to having to be aware of the new hbase:root region from the get go. 2.b If hbase:meta region is split. Users/Operators only have to worry about hbase:meta regions (which one would have to in any split meta implementation), no new hbase:root table to worry about. Although yes one would need to be aware of the first meta region getting assigned first. 3. I think it might also be smoother to get reviewed and checked in 3.a Intuitively given 1 & 2, I think it might be easier to add things more piece meal vs root table > 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)
[jira] [Comment Edited] (HBASE-25761) POC: hbase:meta,,1 as ROOT
[ https://issues.apache.org/jira/browse/HBASE-25761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364035#comment-17364035 ] Francis Christopher Liu edited comment on HBASE-25761 at 6/16/21, 3:27 AM: --- Thanks for your comment [~zhangduo]. >From what I can gather from the rough PoC that I did was that the salient >difference between this implementation and the root table implementation is >around the theme of backward compatibility. Some of which might seem valuable >to the community hence I wonder what the community thinks: 1. The compatibility code is built-in as part of the core implementation there is no extra code to support backward compatibility 2. It introduces no new major artifacts, such that: 2.a If hbase:meta region is not split it operationally will behave pretty much exactly the same way as before (no operator changes, user changes, etc). As opposed to having to be aware of the new hbase:root region from the get go. 2.b If hbase:meta region is split. Users/Operators only have to worry about hbase:meta regions (which one would have to in any split meta implementation), no new hbase:root table to worry about. Although yes one would need to be aware of the first meta region getting assigned first. 3. I think it might also be smoother to get reviewed and checked in 3.a Intuitively given 1 & 2, I think it might be easier to add things more piece meal vs root table was (Author: toffer): Thanks for your comment [~zhangduo]. >From what I can gather from the rough PoC that I did was that the salient >difference between this implementation and the root table implementation is >around the theme of backward compatibility. Some of which might seem valuable >to the community hence I wonder what the community thinks: 1. The compatibility code is built-in as part of the core implementation there is no extra code to support backward compatibility 2. It introduces no new major artifacts, such that: - If hbase:meta region is not split it operationally will behave pretty much exactly the same way as before (no operator changes, user changes, etc). As opposed to having to be aware of the new hbase:root region from the get go. - If hbase:meta region is split. Users/Operators only have to worry about hbase:meta regions (which one would have to in any split meta implementation), no new hbase:root table to worry about. Although yes one would need to be aware of the first meta region getting assigned first. 3. I think it might also be smoother to get reviewed and checked in - Intuitively given 1 & 2, I think it might be easier to add things more piece meal vs root table > 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)
