[jira] [Updated] (HBASE-24664) Some changing of split region by overall region size rather than only one store size
[ https://issues.apache.org/jira/browse/HBASE-24664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wellington Chevreuil updated HBASE-24664: - Fix Version/s: 2.4.0 3.0.0-alpha-1 > Some changing of split region by overall region size rather than only one > store size > > > Key: HBASE-24664 > URL: https://issues.apache.org/jira/browse/HBASE-24664 > Project: HBase > Issue Type: Improvement > Components: regionserver >Affects Versions: 3.0.0-alpha-1, 2.4.0 >Reporter: Zheng Wang >Assignee: Zheng Wang >Priority: Major > Fix For: 3.0.0-alpha-1, 2.4.0 > > > As a distributed cluster, HBase distribute loads in unit of region, so if > region grows too big, > it will bring some negative effects, such as: > 1. Harder to homogenize disk usage(consider locality) > 2. Might cost more time on region opening > 3. After split, the daughter region might lead to more io cost on compaction > in a short time(if write evenly) > I tried to introduce a new SteppingAllStoresSizeSplitPolicy in HBASE-24530, > but after discussed in comments and related > [thread|https://lists.apache.org/thread.html/r08a8103e2532eb667a0fcb4efa8a4117b3f82e6251bc4bd0bc157c26%40%3Cdev.hbase.apache.org%3E], > finally we decide to change the existing split policy with a new option that > if it should count all store files, and for master it would be true, else > false. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-24664) Some changing of split region by overall region size rather than only one store size
[ https://issues.apache.org/jira/browse/HBASE-24664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wellington Chevreuil updated HBASE-24664: - Affects Version/s: 2.4.0 > Some changing of split region by overall region size rather than only one > store size > > > Key: HBASE-24664 > URL: https://issues.apache.org/jira/browse/HBASE-24664 > Project: HBase > Issue Type: Improvement > Components: regionserver >Affects Versions: 3.0.0-alpha-1, 2.4.0 >Reporter: Zheng Wang >Assignee: Zheng Wang >Priority: Major > > As a distributed cluster, HBase distribute loads in unit of region, so if > region grows too big, > it will bring some negative effects, such as: > 1. Harder to homogenize disk usage(consider locality) > 2. Might cost more time on region opening > 3. After split, the daughter region might lead to more io cost on compaction > in a short time(if write evenly) > I tried to introduce a new SteppingAllStoresSizeSplitPolicy in HBASE-24530, > but after discussed in comments and related > [thread|https://lists.apache.org/thread.html/r08a8103e2532eb667a0fcb4efa8a4117b3f82e6251bc4bd0bc157c26%40%3Cdev.hbase.apache.org%3E], > finally we decide to change the existing split policy with a new option that > if it should count all store files, and for master it would be true, else > false. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-24664) Some changing of split region by overall region size rather than only one store size
[ https://issues.apache.org/jira/browse/HBASE-24664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wellington Chevreuil updated HBASE-24664: - Affects Version/s: 3.0.0-alpha-1 > Some changing of split region by overall region size rather than only one > store size > > > Key: HBASE-24664 > URL: https://issues.apache.org/jira/browse/HBASE-24664 > Project: HBase > Issue Type: Improvement > Components: regionserver >Affects Versions: 3.0.0-alpha-1 >Reporter: Zheng Wang >Assignee: Zheng Wang >Priority: Major > > As a distributed cluster, HBase distribute loads in unit of region, so if > region grows too big, > it will bring some negative effects, such as: > 1. Harder to homogenize disk usage(consider locality) > 2. Might cost more time on region opening > 3. After split, the daughter region might lead to more io cost on compaction > in a short time(if write evenly) > I tried to introduce a new SteppingAllStoresSizeSplitPolicy in HBASE-24530, > but after discussed in comments and related > [thread|https://lists.apache.org/thread.html/r08a8103e2532eb667a0fcb4efa8a4117b3f82e6251bc4bd0bc157c26%40%3Cdev.hbase.apache.org%3E], > finally we decide to change the existing split policy with a new option that > if it should count all store files, and for master it would be true, else > false. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-24664) Some changing of split region by overall region size rather than only one store size
[ https://issues.apache.org/jira/browse/HBASE-24664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Wang updated HBASE-24664: --- Description: As a distributed cluster, HBase distribute loads in unit of region, so if region grows too big, it will bring some negative effects, such as: 1. Harder to homogenize disk usage(consider locality) 2. Might cost more time on region opening 3. After split, the daughter region might lead to more io cost on compaction in a short time(if write evenly) I tried to introduce a new SteppingAllStoresSizeSplitPolicy in HBASE-24530, but after discussed in comments and related [thread|https://lists.apache.org/thread.html/r08a8103e2532eb667a0fcb4efa8a4117b3f82e6251bc4bd0bc157c26%40%3Cdev.hbase.apache.org%3E], finally we decide to change the existing split policy with a new option that if it should count all store files, and for master it would be true, else false. was: As a distributed cluster, HBase distribute loads in unit of region, so if region grows too big, it will bring some negative effects, such as: 1. Harder to homogenize disk usage(consider locality) 2. Might cost more time on region opening 3. After split, the daughter region might lead to more io cost on compaction in a short time(if write evenly) I tried to introduce a new SteppingAllStoresSizeSplitPolicy in HBASE-24530, but after discussed in comments and related [thread|https://lists.apache.org/thread.html/r08a8103e2532eb667a0fcb4efa8a4117b3f82e6251bc4bd0bc157c26%40%3Cdev.hbase.apache.org%3E], finally we decide to change the existing split policy with a new option that if it should count all store files, and for mater it would be true, else false. > Some changing of split region by overall region size rather than only one > store size > > > Key: HBASE-24664 > URL: https://issues.apache.org/jira/browse/HBASE-24664 > Project: HBase > Issue Type: Improvement > Components: regionserver >Reporter: Zheng Wang >Assignee: Zheng Wang >Priority: Major > > As a distributed cluster, HBase distribute loads in unit of region, so if > region grows too big, > it will bring some negative effects, such as: > 1. Harder to homogenize disk usage(consider locality) > 2. Might cost more time on region opening > 3. After split, the daughter region might lead to more io cost on compaction > in a short time(if write evenly) > I tried to introduce a new SteppingAllStoresSizeSplitPolicy in HBASE-24530, > but after discussed in comments and related > [thread|https://lists.apache.org/thread.html/r08a8103e2532eb667a0fcb4efa8a4117b3f82e6251bc4bd0bc157c26%40%3Cdev.hbase.apache.org%3E], > finally we decide to change the existing split policy with a new option that > if it should count all store files, and for master it would be true, else > false. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-24664) Some changing of split region by overall region size rather than only one store size
[ https://issues.apache.org/jira/browse/HBASE-24664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Wang updated HBASE-24664: --- Description: As a distributed cluster, HBase distribute loads in unit of region, so if region grows too big, it will bring some negative effects, such as: 1. Harder to homogenize disk usage(consider locality) 2. Might cost more time on region opening 3. After split, the daughter region might lead to more io cost on compaction in a short time(if write evenly) I tried to introduce a new SteppingAllStoresSizeSplitPolicy in HBASE-24530, but after discussed in comments and related [thread|https://lists.apache.org/thread.html/r08a8103e2532eb667a0fcb4efa8a4117b3f82e6251bc4bd0bc157c26%40%3Cdev.hbase.apache.org%3E],finally we decide to change the existing split policy with a new option that if it should count all store files, and for mater it would be true, else false. was: As a distributed cluster, HBase distribute loads in unit of region, so if region grows too big, it will bring some negative effects, such as: 1. Harder to homogenize disk usage(consider locality) 2. Might cost more time on region opening 3. After split, the daughter region might lead to more io cost on compaction in a short time(if write evenly) I tried to introduce a new SteppingAllStoresSizeSplitPolicy in HBASE-24530, but after discussed in comments and related [thread|https://lists.apache.org/thread.html/r08a8103e2532eb667a0fcb4efa8a4117b3f82e6251bc4bd0bc157c26%40%3Cdev.hbase.apache.org%3E], finally we decide to change the existing split policy with a new option that if it should count all store files, and for mater it would be true, else false. > Some changing of split region by overall region size rather than only one > store size > > > Key: HBASE-24664 > URL: https://issues.apache.org/jira/browse/HBASE-24664 > Project: HBase > Issue Type: Improvement > Components: regionserver >Reporter: Zheng Wang >Assignee: Zheng Wang >Priority: Major > > As a distributed cluster, HBase distribute loads in unit of region, so if > region grows too big, > it will bring some negative effects, such as: > 1. Harder to homogenize disk usage(consider locality) > 2. Might cost more time on region opening > 3. After split, the daughter region might lead to more io cost on compaction > in a short time(if write evenly) > I tried to introduce a new SteppingAllStoresSizeSplitPolicy in HBASE-24530, > but after discussed in comments and related > [thread|https://lists.apache.org/thread.html/r08a8103e2532eb667a0fcb4efa8a4117b3f82e6251bc4bd0bc157c26%40%3Cdev.hbase.apache.org%3E],finally > we decide to change the existing split policy with a new option that if it > should count all store files, and for mater it would be true, else false. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-24664) Some changing of split region by overall region size rather than only one store size
[ https://issues.apache.org/jira/browse/HBASE-24664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Wang updated HBASE-24664: --- Description: As a distributed cluster, HBase distribute loads in unit of region, so if region grows too big, it will bring some negative effects, such as: 1. Harder to homogenize disk usage(consider locality) 2. Might cost more time on region opening 3. After split, the daughter region might lead to more io cost on compaction in a short time(if write evenly) I tried to introduce a new SteppingAllStoresSizeSplitPolicy in HBASE-24530, but after discussed in comments and related [thread|https://lists.apache.org/thread.html/r08a8103e2532eb667a0fcb4efa8a4117b3f82e6251bc4bd0bc157c26%40%3Cdev.hbase.apache.org%3E], finally we decide to change the existing split policy with a new option that if it should count all store files, and for mater it would be true, else false. was: As a distributed cluster, HBase distribute loads in unit of region, so if region grows too big, it will bring some negative effects, such as: 1. Harder to homogenize disk usage(consider locality) 2. Might cost more time on region opening 3. After split, the daughter region might lead to more io cost on compaction in a short time(if write evenly) HBASE-24530 introduced a new SteppingAllStoresSizeSplitPolicy, and as discussed in its comments and related [thread|https://lists.apache.org/thread.html/r08a8103e2532eb667a0fcb4efa8a4117b3f82e6251bc4bd0bc157c26%40%3Cdev.hbase.apache.org%3E], we should do follow-on tasks in this new issue. 1. Set SteppingAllStoresSizeSplitPolicy as default 2. Mark SteppingSplitPolicy and IncreasingToUpperBoundRegionSplitPolicy as deprecated 3. Fix ConstantSizeRegionSplitPolicy to split region by overall region size also > Some changing of split region by overall region size rather than only one > store size > > > Key: HBASE-24664 > URL: https://issues.apache.org/jira/browse/HBASE-24664 > Project: HBase > Issue Type: Improvement > Components: regionserver >Reporter: Zheng Wang >Assignee: Zheng Wang >Priority: Major > > As a distributed cluster, HBase distribute loads in unit of region, so if > region grows too big, > it will bring some negative effects, such as: > 1. Harder to homogenize disk usage(consider locality) > 2. Might cost more time on region opening > 3. After split, the daughter region might lead to more io cost on compaction > in a short time(if write evenly) > I tried to introduce a new SteppingAllStoresSizeSplitPolicy in HBASE-24530, > but after discussed in comments and related > [thread|https://lists.apache.org/thread.html/r08a8103e2532eb667a0fcb4efa8a4117b3f82e6251bc4bd0bc157c26%40%3Cdev.hbase.apache.org%3E], > finally we decide to change the existing split policy with a new option that > if it should count all store files, and for mater it would be true, else > false. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-24664) Some changing of split region by overall region size rather than only one store size
[ https://issues.apache.org/jira/browse/HBASE-24664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Wang updated HBASE-24664: --- Description: As a distributed cluster, HBase distribute loads in unit of region, so if region grows too big, it will bring some negative effects, such as: 1. Harder to homogenize disk usage(consider locality) 2. Might cost more time on region opening 3. After split, the daughter region might lead to more io cost on compaction in a short time(if write evenly) I tried to introduce a new SteppingAllStoresSizeSplitPolicy in HBASE-24530, but after discussed in comments and related [thread|https://lists.apache.org/thread.html/r08a8103e2532eb667a0fcb4efa8a4117b3f82e6251bc4bd0bc157c26%40%3Cdev.hbase.apache.org%3E], finally we decide to change the existing split policy with a new option that if it should count all store files, and for mater it would be true, else false. was: As a distributed cluster, HBase distribute loads in unit of region, so if region grows too big, it will bring some negative effects, such as: 1. Harder to homogenize disk usage(consider locality) 2. Might cost more time on region opening 3. After split, the daughter region might lead to more io cost on compaction in a short time(if write evenly) I tried to introduce a new SteppingAllStoresSizeSplitPolicy in HBASE-24530, but after discussed in comments and related [thread|https://lists.apache.org/thread.html/r08a8103e2532eb667a0fcb4efa8a4117b3f82e6251bc4bd0bc157c26%40%3Cdev.hbase.apache.org%3E],finally we decide to change the existing split policy with a new option that if it should count all store files, and for mater it would be true, else false. > Some changing of split region by overall region size rather than only one > store size > > > Key: HBASE-24664 > URL: https://issues.apache.org/jira/browse/HBASE-24664 > Project: HBase > Issue Type: Improvement > Components: regionserver >Reporter: Zheng Wang >Assignee: Zheng Wang >Priority: Major > > As a distributed cluster, HBase distribute loads in unit of region, so if > region grows too big, > it will bring some negative effects, such as: > 1. Harder to homogenize disk usage(consider locality) > 2. Might cost more time on region opening > 3. After split, the daughter region might lead to more io cost on compaction > in a short time(if write evenly) > I tried to introduce a new SteppingAllStoresSizeSplitPolicy in HBASE-24530, > but after discussed in comments and related > [thread|https://lists.apache.org/thread.html/r08a8103e2532eb667a0fcb4efa8a4117b3f82e6251bc4bd0bc157c26%40%3Cdev.hbase.apache.org%3E], > finally we decide to change the existing split policy with a new option that > if it should count all store files, and for mater it would be true, else > false. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-24664) Some changing of split region by overall region size rather than only one store size
[ https://issues.apache.org/jira/browse/HBASE-24664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Wang updated HBASE-24664: --- Description: As a distributed cluster, HBase distribute loads in unit of region, so if region grows too big, it will bring some negative effects, such as: 1. Harder to homogenize disk usage(consider locality) 2. Might cost more time on region opening 3. After split, the daughter region might lead to more io cost on compaction in a short time(if write evenly) HBASE-24530 introduced a new SteppingAllStoresSizeSplitPolicy, and as discussed in its comments and related [thread|https://lists.apache.org/thread.html/r08a8103e2532eb667a0fcb4efa8a4117b3f82e6251bc4bd0bc157c26%40%3Cdev.hbase.apache.org%3E], we should do follow-on tasks in this new issue. 1. Set SteppingAllStoresSizeSplitPolicy as default 2. Mark SteppingSplitPolicy and IncreasingToUpperBoundRegionSplitPolicy.java as deprecated 3. Fix ConstantSizeRegionSplitPolicy to split region by overall region size also was: As a distributed cluster, HBase distribute loads in unit of region, so if region grows too big, it will bring some negative effects, such as: 1. Harder to homogenize disk usage(consider locality) 2. Might cost more time on region opening 3. After split, the daughter region might lead to more io cost on compaction in a short time(if write evenly) HBASE-24530 introduced a new SteppingAllStoresSizeSplitPolicy, and as discussed in its comments and related [thread|https://lists.apache.org/thread.html/r08a8103e2532eb667a0fcb4efa8a4117b3f82e6251bc4bd0bc157c26%40%3Cdev.hbase.apache.org%3E], we should do follow-on tasks in this new issue. 1. Set SteppingAllStoresSizeSplitPolicy as default 2. Mark SteppingSplitPolicy and IncreasingToUpperBoundRegionSplitPolicy.java as deprecated 3. Fix ConstantSizeRegionSplitPolicy to split region by overall region size also > Some changing of split region by overall region size rather than only one > store size > > > Key: HBASE-24664 > URL: https://issues.apache.org/jira/browse/HBASE-24664 > Project: HBase > Issue Type: Improvement > Components: regionserver >Reporter: Zheng Wang >Assignee: Zheng Wang >Priority: Major > > As a distributed cluster, HBase distribute loads in unit of region, so if > region grows too big, > it will bring some negative effects, such as: > 1. Harder to homogenize disk usage(consider locality) > 2. Might cost more time on region opening > 3. After split, the daughter region might lead to more io cost on compaction > in a short time(if write evenly) > HBASE-24530 introduced a new SteppingAllStoresSizeSplitPolicy, and as > discussed in its comments and related > [thread|https://lists.apache.org/thread.html/r08a8103e2532eb667a0fcb4efa8a4117b3f82e6251bc4bd0bc157c26%40%3Cdev.hbase.apache.org%3E], > we should do follow-on tasks in this new issue. > 1. Set SteppingAllStoresSizeSplitPolicy as default > 2. Mark SteppingSplitPolicy and IncreasingToUpperBoundRegionSplitPolicy.java > as deprecated > 3. Fix ConstantSizeRegionSplitPolicy to split region by overall region size > also -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-24664) Some changing of split region by overall region size rather than only one store size
[ https://issues.apache.org/jira/browse/HBASE-24664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Wang updated HBASE-24664: --- Description: As a distributed cluster, HBase distribute loads in unit of region, so if region grows too big, it will bring some negative effects, such as: 1. Harder to homogenize disk usage(consider locality) 2. Might cost more time on region opening 3. After split, the daughter region might lead to more io cost on compaction in a short time(if write evenly) HBASE-24530 introduced a new SteppingAllStoresSizeSplitPolicy, and as discussed in its comments and related [thread|https://lists.apache.org/thread.html/r08a8103e2532eb667a0fcb4efa8a4117b3f82e6251bc4bd0bc157c26%40%3Cdev.hbase.apache.org%3E], we should do follow-on tasks in this new issue. 1. Set SteppingAllStoresSizeSplitPolicy as default 2. Mark SteppingSplitPolicy and IncreasingToUpperBoundRegionSplitPolicy as deprecated 3. Fix ConstantSizeRegionSplitPolicy to split region by overall region size also was: As a distributed cluster, HBase distribute loads in unit of region, so if region grows too big, it will bring some negative effects, such as: 1. Harder to homogenize disk usage(consider locality) 2. Might cost more time on region opening 3. After split, the daughter region might lead to more io cost on compaction in a short time(if write evenly) HBASE-24530 introduced a new SteppingAllStoresSizeSplitPolicy, and as discussed in its comments and related [thread|https://lists.apache.org/thread.html/r08a8103e2532eb667a0fcb4efa8a4117b3f82e6251bc4bd0bc157c26%40%3Cdev.hbase.apache.org%3E], we should do follow-on tasks in this new issue. 1. Set SteppingAllStoresSizeSplitPolicy as default 2. Mark SteppingSplitPolicy and IncreasingToUpperBoundRegionSplitPolicy.java as deprecated 3. Fix ConstantSizeRegionSplitPolicy to split region by overall region size also > Some changing of split region by overall region size rather than only one > store size > > > Key: HBASE-24664 > URL: https://issues.apache.org/jira/browse/HBASE-24664 > Project: HBase > Issue Type: Improvement > Components: regionserver >Reporter: Zheng Wang >Assignee: Zheng Wang >Priority: Major > > As a distributed cluster, HBase distribute loads in unit of region, so if > region grows too big, > it will bring some negative effects, such as: > 1. Harder to homogenize disk usage(consider locality) > 2. Might cost more time on region opening > 3. After split, the daughter region might lead to more io cost on compaction > in a short time(if write evenly) > HBASE-24530 introduced a new SteppingAllStoresSizeSplitPolicy, and as > discussed in its comments and related > [thread|https://lists.apache.org/thread.html/r08a8103e2532eb667a0fcb4efa8a4117b3f82e6251bc4bd0bc157c26%40%3Cdev.hbase.apache.org%3E], > we should do follow-on tasks in this new issue. > 1. Set SteppingAllStoresSizeSplitPolicy as default > 2. Mark SteppingSplitPolicy and IncreasingToUpperBoundRegionSplitPolicy as > deprecated > 3. Fix ConstantSizeRegionSplitPolicy to split region by overall region size > also -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-24664) Some changing of split region by overall region size rather than only one store size
[ https://issues.apache.org/jira/browse/HBASE-24664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Wang updated HBASE-24664: --- Description: As a distributed cluster, HBase distribute loads in unit of region, so if region grows too big, it will bring some negative effects, such as: 1. Harder to homogenize disk usage(consider locality) 2. Might cost more time on region opening 3. After split, the daughter region might lead to more io cost on compaction in a short time(if write evenly) HBASE-24530 introduced a new SteppingAllStoresSizeSplitPolicy, and as discussed in its comments and related [thread|https://lists.apache.org/thread.html/r08a8103e2532eb667a0fcb4efa8a4117b3f82e6251bc4bd0bc157c26%40%3Cdev.hbase.apache.org%3E], we should do follow-on tasks in this new issue. 1. Set SteppingAllStoresSizeSplitPolicy as default 2. Mark SteppingSplitPolicy and IncreasingToUpperBoundRegionSplitPolicy.java as deprecated 3. Fix ConstantSizeRegionSplitPolicy to split region by overall region size also was: As a distributed cluster, HBase distribute loads in unit of region, so if region grows too big, it will bring some negative effects, such as: 1. Harder to homogenize disk usage(consider locality) 2. Might cost more time on region opening 3. After split, the daughter region might lead to more io cost on compaction in a short time(if write evenly) HBASE-24530 introduced a new SteppingAllStoresSizeSplitPolicy, and as discussed in its comments and related [thread|http://example.com], we should do follow-on tasks in this new issue. 1. Set SteppingAllStoresSizeSplitPolicy as default 2. Mark SteppingSplitPolicy and IncreasingToUpperBoundRegionSplitPolicy.java as deprecated 3. Fix ConstantSizeRegionSplitPolicy to split region by overall region size also > Some changing of split region by overall region size rather than only one > store size > > > Key: HBASE-24664 > URL: https://issues.apache.org/jira/browse/HBASE-24664 > Project: HBase > Issue Type: Improvement > Components: regionserver >Reporter: Zheng Wang >Assignee: Zheng Wang >Priority: Major > > As a distributed cluster, HBase distribute loads in unit of region, so if > region grows too big, > it will bring some negative effects, such as: > 1. Harder to homogenize disk usage(consider locality) > 2. Might cost more time on region opening > 3. After split, the daughter region might lead to more io cost on compaction > in a short time(if write evenly) > HBASE-24530 introduced a new SteppingAllStoresSizeSplitPolicy, and as > discussed in its comments and related > [thread|https://lists.apache.org/thread.html/r08a8103e2532eb667a0fcb4efa8a4117b3f82e6251bc4bd0bc157c26%40%3Cdev.hbase.apache.org%3E], > we should do follow-on tasks in this new issue. > 1. Set SteppingAllStoresSizeSplitPolicy as default > 2. Mark SteppingSplitPolicy and IncreasingToUpperBoundRegionSplitPolicy.java > as deprecated > 3. Fix ConstantSizeRegionSplitPolicy to split region by overall region size > also -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-24664) Some changing of split region by overall region size rather than only one store size
[ https://issues.apache.org/jira/browse/HBASE-24664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Wang updated HBASE-24664: --- Description: As a distributed cluster, HBase distribute loads in unit of region, so if region grows too big, it will bring some negative effects, such as: 1. Harder to homogenize disk usage(consider locality) 2. Might cost more time on region opening 3. After split, the daughter region might lead to more io cost on compaction in a short time(if write evenly) HBASE-24530 introduced a new SteppingAllStoresSizeSplitPolicy, and as discussed in its comments and related [thread|http://example.com], we should do follow-on tasks in this new issue. 1. Set SteppingAllStoresSizeSplitPolicy as default 2. Mark SteppingSplitPolicy and IncreasingToUpperBoundRegionSplitPolicy.java as deprecated 3. Fix ConstantSizeRegionSplitPolicy to split region by overall region size also was: As a distributed cluster, HBase distribute loads in unit of region, so if region grows too big, it will bring some negative effects, such as: 1. Harder to homogenize disk usage(consider locality) 2. Might cost more time on region opening 3. After split, the daughter region might lead to more io cost on compaction in a short time(if write evenly) HBASE-24530 introduced a new SteppingAllStoresSizeSplitPolicy, and as discussed in its comments and related thread[link title|[https://lists.apache.org/thread.html/r08a8103e2532eb667a0fcb4efa8a4117b3f82e6251bc4bd0bc157c26%40%3Cdev.hbase.apache.org%3E]], we should do follow-on tasks in this new issue. 1. Set SteppingAllStoresSizeSplitPolicy as default 2. Mark SteppingSplitPolicy and IncreasingToUpperBoundRegionSplitPolicy.java as deprecated 3. Fix ConstantSizeRegionSplitPolicy to split region by overall region size also > Some changing of split region by overall region size rather than only one > store size > > > Key: HBASE-24664 > URL: https://issues.apache.org/jira/browse/HBASE-24664 > Project: HBase > Issue Type: Improvement > Components: regionserver >Reporter: Zheng Wang >Assignee: Zheng Wang >Priority: Major > > As a distributed cluster, HBase distribute loads in unit of region, so if > region grows too big, > it will bring some negative effects, such as: > 1. Harder to homogenize disk usage(consider locality) > 2. Might cost more time on region opening > 3. After split, the daughter region might lead to more io cost on compaction > in a short time(if write evenly) > HBASE-24530 introduced a new SteppingAllStoresSizeSplitPolicy, and as > discussed in its comments and related [thread|http://example.com], > we should do follow-on tasks in this new issue. > 1. Set SteppingAllStoresSizeSplitPolicy as default > 2. Mark SteppingSplitPolicy and IncreasingToUpperBoundRegionSplitPolicy.java > as deprecated > 3. Fix ConstantSizeRegionSplitPolicy to split region by overall region size > also -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-24664) Some changing of split region by overall region size rather than only one store size
[ https://issues.apache.org/jira/browse/HBASE-24664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Wang updated HBASE-24664: --- Description: As a distributed cluster, HBase distribute loads in unit of region, so if region grows too big, it will bring some negative effects, such as: 1. Harder to homogenize disk usage(consider locality) 2. Might cost more time on region opening 3. After split, the daughter region might lead to more io cost on compaction in a short time(if write evenly) HBASE-24530 introduced a new SteppingAllStoresSizeSplitPolicy, and as discussed in its comments and related thread[link title|[https://lists.apache.org/thread.html/r08a8103e2532eb667a0fcb4efa8a4117b3f82e6251bc4bd0bc157c26%40%3Cdev.hbase.apache.org%3E]], we should do follow-on tasks in this new issue. 1. Set SteppingAllStoresSizeSplitPolicy as default 2. Mark SteppingSplitPolicy and IncreasingToUpperBoundRegionSplitPolicy.java as deprecated 3. Fix ConstantSizeRegionSplitPolicy to split region by overall region size also was: As a distributed cluster, HBase distribute loads in unit of region, so if region grows too big, it will bring some negative effects, such as: 1. Harder to homogenize disk usage(consider locality) 2. Might cost more time on region opening 3. After split, the daughter region might lead to more io cost on compaction in a short time(if write evenly) HBASE-24530 introduced a new SteppingAllStoresSizeSplitPolicy, and as discussed in its comments and related [thread|[https://lists.apache.org/thread.html/r08a8103e2532eb667a0fcb4efa8a4117b3f82e6251bc4bd0bc157c26%40%3Cdev.hbase.apache.org%3E]], we should do follow-on tasks in this new issue. 1. Set SteppingAllStoresSizeSplitPolicy as default 2. Mark SteppingSplitPolicy and IncreasingToUpperBoundRegionSplitPolicy.java as deprecated 3. Fix ConstantSizeRegionSplitPolicy to split region by overall region size also > Some changing of split region by overall region size rather than only one > store size > > > Key: HBASE-24664 > URL: https://issues.apache.org/jira/browse/HBASE-24664 > Project: HBase > Issue Type: Improvement > Components: regionserver >Reporter: Zheng Wang >Assignee: Zheng Wang >Priority: Major > > As a distributed cluster, HBase distribute loads in unit of region, so if > region grows too big, > it will bring some negative effects, such as: > 1. Harder to homogenize disk usage(consider locality) > 2. Might cost more time on region opening > 3. After split, the daughter region might lead to more io cost on compaction > in a short time(if write evenly) > HBASE-24530 introduced a new SteppingAllStoresSizeSplitPolicy, and as > discussed in its comments and related thread[link > title|[https://lists.apache.org/thread.html/r08a8103e2532eb667a0fcb4efa8a4117b3f82e6251bc4bd0bc157c26%40%3Cdev.hbase.apache.org%3E]], > we should do follow-on tasks in this new issue. > 1. Set SteppingAllStoresSizeSplitPolicy as default > 2. Mark SteppingSplitPolicy and IncreasingToUpperBoundRegionSplitPolicy.java > as deprecated > 3. Fix ConstantSizeRegionSplitPolicy to split region by overall region size > also -- This message was sent by Atlassian Jira (v8.3.4#803005)
