-
Notifications
You must be signed in to change notification settings - Fork 757
Description
Feature Request
Describe your feature request related problem
PD currently allocates keyspace IDs monotonically in createKeyspace.
Because the encoded key range of a new keyspace is derived from its keyspace ID, newly created keyspaces are continuously appended to the highest key range. This means repeated createKeyspace requests tend to always split the rightmost region.
In workloads that create many keyspaces, this can concentrate split pressure on the same region and may lead to hotspot behavior during region split and scatter.
Describe the feature you'd like
PD should avoid always allocating keyspace IDs in a strictly monotonic way for createKeyspace, or provide an equivalent mechanism that distributes newly created keyspaces more evenly across physical key ranges.
The goal is to reduce repeated rightmost-region splits and avoid creating a hot split point when keyspaces are created continuously.
Describe alternatives you've considered
- Keep the current monotonic allocation and rely on later balancing or scattering.
- Pre-allocate multiple keyspace ID ranges and distribute allocations across them.
- Introduce a mapping layer so logical keyspace creation order does not always map to the largest physical key range.
- Batch or randomize allocation in a controlled way, as long as compatibility requirements are preserved.
Teachability, Documentation, Adoption, Migration Strategy
This improvement should ideally be transparent to users if keyspace ID ordering is not part of the external contract.
If there are components that rely on monotonic keyspace IDs, the constraints should be documented and an alternative distribution strategy should preserve compatibility.