[
https://issues.apache.org/jira/browse/HBASE-25382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang updated HBASE-25382:
------------------------------
Description:
Currently, the hbase:meta Table is made of one Region only. It is not
splittable. We would like to make it so the hbase:meta table can be split just
as we for user-space tables as they grow in size.
Why split the hbase:meta table?
{quote}A single Region _hbase:meta_ Table hotspots as cluster size grows. At
extreme, hotspotting brings on special-casing with deploys dedicating nodes
solely to the hosting of the single _hbase:meta_ Region to better carry the
higher load (but also to isolate _hbase:meta_ if heavily trafficked neighbor
Regions). Splitting, currently disallowed, will enable distributing the
_hbase:meta_ Table Regions, and thereby load, across the cluster. A splittable
_hbase:meta_ table will also alleviate concerns enlarging the _hbase:meta_
table whether by adding more meta data per Region entry -- e.g. keeping the
list of Region HFiles in the _hbase:meta_ table -- or running with more,
smaller Regions rather than a few large Regions.
{quote}
This is not the first issue to concern itself with meta splitting (HBASE-11288,
HBASE-24950). By aggreement. -- see the base of HBASE-11288 -- this issue
supplants all previous JIRAs and design efforts. It is a reset. We start by
listing requirements in the attached Super Split Meta Design.
was:
Currently, the hbase:meta Table is made of one Region only. It is not
splittable. We would like to make it so the hbase:meta table can be split just
as we for user-space tables as they grow in size.
Why split the hbase:meta table?
{quote}A single Region _hbase:meta_ Table hotspots as cluster size grows. At
extreme, hotspotting brings on special-casing with deploys dedicating nodes
solely to the hosting of the single _hbase:meta_ Region to better carry the
higher load (but also to isolate _hbase:meta_ if heavily trafficked neighbor
Regions). Splitting, currently disallowed, will enable distributing the
_hbase:meta_ Table Regions, and thereby load, across the cluster. A splittable
_hbase:meta_ table will also alleviate concerns enlarging the _hbase:meta_
table whether by adding more meta data per Region entry -- e.g. keeping the
list of Region HFiles in the _hbase:meta_ table -- or running with more,
smaller Regions rather than a few large Regions.
{quote}
This is not the first issue to concern itself with meta splitting (HBASE-11288,
HBASE-24391). By aggreement. -- see the base of HBASE-11288 -- this issue
supplants all previous JIRAs and design efforts. It is a reset. We start by
listing requirements in the attached Super Split Meta Design.
> Super Split Meta
> ----------------
>
> Key: HBASE-25382
> URL: https://issues.apache.org/jira/browse/HBASE-25382
> Project: HBase
> Issue Type: Umbrella
> Components: meta
> Reporter: Michael Stack
> Priority: Major
>
> Currently, the hbase:meta Table is made of one Region only. It is not
> splittable. We would like to make it so the hbase:meta table can be split
> just as we for user-space tables as they grow in size.
> Why split the hbase:meta table?
> {quote}A single Region _hbase:meta_ Table hotspots as cluster size grows. At
> extreme, hotspotting brings on special-casing with deploys dedicating nodes
> solely to the hosting of the single _hbase:meta_ Region to better carry the
> higher load (but also to isolate _hbase:meta_ if heavily trafficked neighbor
> Regions). Splitting, currently disallowed, will enable distributing the
> _hbase:meta_ Table Regions, and thereby load, across the cluster. A
> splittable _hbase:meta_ table will also alleviate concerns enlarging the
> _hbase:meta_ table whether by adding more meta data per Region entry -- e.g.
> keeping the list of Region HFiles in the _hbase:meta_ table -- or running
> with more, smaller Regions rather than a few large Regions.
> {quote}
> This is not the first issue to concern itself with meta splitting
> (HBASE-11288, HBASE-24950). By aggreement. -- see the base of HBASE-11288 --
> this issue supplants all previous JIRAs and design efforts. It is a reset. We
> start by listing requirements in the attached Super Split Meta Design.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
