Partition ring proposal #6932
Open
Partition ring proposal #6932
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
danielblando
force-pushed
the
partitionRingProposal
branch
2 times, most recently
from
ccbc6f4 to
7e4c73f
Compare
Signed-off-by: Daniel Deluiggi <[email protected]>
danielblando
force-pushed
the
partitionRingProposal
branch
from
7e4c73f to
0ec86eb
Compare
anna-tran
approved these changes
Aug 1, 2025
friedrichg
approved these changes
Aug 2, 2025
|
|
||
| ### Partition Ring Architecture | ||
|
|
||
| A new Partition Ring is proposed where the ring is divided into partitions, with each partition containing a set of tokens and a group of ingesters. Ingesters are allocated to partitions based on their order in the zonal StatefulSet, ensuring that scaling operations align with StatefulSet's LIFO behavior. Each partition contains a number of ingesters equal to the replication factor, with exactly one ingester per availability zone. |
There was a problem hiding this comment.
Considering your well described current behavior
- Hashes the series labels to get a hash value
- Finds the primary ingester (smallest token > hash value)
- When replication is enabled, selects additional replicas by moving clockwise around the ring
- Ensures replicas are distributed across different availability zones
We will now find the next partition instead of the next ingester (2) using the same hash as before. Finding the 3 ingesters from the partition (3). Ingesters in partitions are already in different zones, so no need for 4.
Am I understanding it correctly?
There was a problem hiding this comment.
Kind of. I am not sure if i understood your "find the next partition". We only need to find one partition with the new approach.
We will do
- Hashes the series labels to get a hash value
- Finds the partition owning smaller token based on hashed value
- Get all ingester which are part of that partition
|
@friedrichg thanks. I am not sure if i have any reference. I did add a POC i done to prove the concept before. But it is mostly code |
|
Looks promising, thanks |
SungJin1212
approved these changes
Aug 8, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What this PR does:
Submitting a proposal for partition ring to improve write availability with replication factor
A POC done for reference:
PartitionRing: danielblando@3e78f32
MultiRing: danielblando@dbae52c
Checklist
CHANGELOG.mdupdated - the order of entries should be[CHANGE],[FEATURE],[ENHANCEMENT],[BUGFIX]