You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Alexey Serbin (Jira)" <ji...@apache.org> on 2022/04/08 21:17:00 UTC

[jira] [Resolved] (KUDU-3147) Balance tablets based on range hash buckets

     [ https://issues.apache.org/jira/browse/KUDU-3147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Serbin resolved KUDU-3147.
---------------------------------
    Fix Version/s: 1.17.0
       Resolution: Fixed

The {{kudu cluster rebalance}} tool now supports range-rebalancing (as of now, just for a single table per run, but the functionality is there): https://github.com/apache/kudu/commit/01ca8c3f2bb38bc8b738d86d3d88aa8d1ffaad87

> Balance tablets based on range hash buckets
> -------------------------------------------
>
>                 Key: KUDU-3147
>                 URL: https://issues.apache.org/jira/browse/KUDU-3147
>             Project: Kudu
>          Issue Type: Improvement
>          Components: master, perf
>    Affects Versions: 1.12.0
>            Reporter: Grant Henke
>            Assignee: Ravi Bhanot
>            Priority: Major
>              Labels: balancer, performance, roadmap-candidate
>             Fix For: 1.17.0
>
>
> When a user defines a schema that uses range + hash partitioning its is often the case that the tablets in the latest range, based on time or any semi-sequential data, are the only tablets that receive writes. Or even if not the latest, it is common for a single range to receive a burst of writes if backloading.
> This is so common, that the default Kudu balancing scheme should consider placing/rebalancing the tablets for the hash buckets within each range on as many servers as possible in order to support the maximum write throughput. In that case, `min(#buckets, #total-cluster-tservers)` tservers will be used to handle the writes if the cluster is perfectly balanced. Today, even if perfectly balanced, it is possible for all the hash buckets to be on a single tserver.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)