New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HBASE-25534 Honor TableDescriptor settings earlier in normalization #2917
Conversation
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a nice improvement. Just a couple comments/requests.
LOG.warn("TableDescriptor for {} unavailable, table-level target region count and size" | ||
+ " configurations cannot be considered.", table, e); | ||
} | ||
long targetRegionCount = tableDescriptor.getNormalizerTargetRegionCount(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: no need to promote this to a long
.
@@ -316,10 +314,10 @@ private double getAverageRegionSizeMb(final List<RegionInfo> tableRegions) { | |||
*/ | |||
private boolean skipForMerge( | |||
final NormalizerConfiguration normalizerConfiguration, | |||
final RegionStates regionStates, | |||
final NormalizeContext ctx, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good.
@@ -468,12 +467,13 @@ private static boolean isOldEnoughForMerge( | |||
*/ | |||
private boolean isLargeEnoughForMerge( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can be static now as well?
} | ||
|
||
private static boolean logTraceReason(final BooleanSupplier predicate, final String fmtWhenTrue, | ||
private boolean logTraceReason(final BooleanSupplier predicate, final String fmtWhenTrue, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why make this an instance method?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find skipForSplit, logTraceReason, isOldEnoughForMerge is static, but it does not need static. I am not sure what is the purpose of setting those to static.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a general practice, when a method can be static, I prefer to make it so. If a method has no need for this
or private state, why expose it? I find static methods are easier to reason about because you know there's no hidden effects of object member variables manipulated elsewhere. I suspect they're simpler for the JIT to optimize for the same reasons, but I don't have evidence of this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the wonderful answers, which benefited me a lot.
@@ -592,5 +621,14 @@ public RegionStates getRegionStates() { | |||
public double getAverageRegionSizeMb() { | |||
return averageRegionSizeMb; | |||
} | |||
|
|||
public <T> T getOrDefault(String key, Function<String, T> function, T defaultValue) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice.
Maybe this method returns an Object
/null
and the caller handles the null-check. I think this approach would be better than using an out-of-range value to indicate the lack of configuration.
} | ||
|
||
@Test | ||
public void testHonorsSplitEnabledInTD() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These tests *EnabledInTD
are good for confirming that the split/merge will not happen when disabled in table descriptor. Please also add coverage of when split/merge is disabled in configuration but enabled in table descriptor. I believe this should be supported, given the new implementations of proceedWith{Split,Merge}Planning
.
Thanks @ndimiduk. Not sure about the static keyword. The rest is done. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the improvement, @ZhaoBQ
…pache#2917) Signed-off-by: Nick Dimiduk <ndimiduk@apache.org>
…2917) Signed-off-by: Nick Dimiduk <ndimiduk@apache.org>
…pache#2917) Signed-off-by: Nick Dimiduk <ndimiduk@apache.org>
…pache#2917) Signed-off-by: Nick Dimiduk <ndimiduk@apache.org>
…lization (apache#2917)" to branch-2
…2917) Signed-off-by: Nick Dimiduk <ndimiduk@apache.org>
Table can be enabled and disabled merge/split in TableDescriptor, we should judge before calculating the plan.
Part of the configuration can be set by table level. For example, hbase.normalizer.min.region.count can be set by "alter ‘table’, CONFIGURATION=>{'hbase.normalizer.min.region.count' => '5'}". If the table is not set, then use the global configuration which is set in hbase-site.xml.