Skip to content
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

Added hashmod support for store sharding. #2172

Merged
merged 1 commit into from
Feb 24, 2020
Merged

Added hashmod support for store sharding. #2172

merged 1 commit into from
Feb 24, 2020

Conversation

bwplotka
Copy link
Member

No description provided.

@@ -401,14 +401,25 @@ func NewLabelShardedMetaFilter(relabelConfig []*relabel.Config) *LabelShardedMet
return &LabelShardedMetaFilter{relabelConfig: relabelConfig}
}

const blockIDLabel = "__block_id"

// Filter filters out blocks that filters blocks that have no labels after relabelling.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment is quite confusing to me. Do the filtered blocks filter out other blocks with no labels? or is there an extra filters out blocks here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I think there is a double filters out blocks.

Copy link
Contributor

@metalmatze metalmatze left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM from just looking at the code! :)

lbls[0] = labels.Label{Name: blockIDLabel, Value: id.String()}
lbls = lbls[:1]
if len(lbls) < len(m.Thanos.Labels) {
lbls = make([]labels.Label, 0, len(m.Thanos.Labels))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this logic is a bit funny I think. If m.Thanos.Labels has length 2, then we throw away the block ID label we set earlier. But if it has length 1, then we keep the block ID label and allocate a new backing array when we append that one single label. Is that what we want to do?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah it looks like in this case we wouldn't end up having the block id label I think. I can see what you were trying to do but is this really that performance sensitive that we need to safe the allocations here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I wanted to save allocs, will fix

@bwplotka
Copy link
Member Author

Addressed all, thanks for detailed review 👍

if processedLabels := relabel.Process(labels.FromMap(m.Thanos.Labels), f.relabelConfig...); processedLabels != nil {
continue
lbls = lbls[:0]
if len(lbls) < len(m.Thanos.Labels)+1 {
Copy link
Member

@brancz brancz Feb 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you reset the length in the line above, I assume you meant to do cap(lbls) on the left side here?

if processedLabels := relabel.Process(labels.FromMap(m.Thanos.Labels), f.relabelConfig...); processedLabels != nil {
continue
lbls = lbls[:0]
if len(lbls) < len(m.Thanos.Labels)+1 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This check is now unnecessary. Here, lbls will ALWAYS be 0 length, and len(m.Thanos.Labels)+1 will ALWAYS be at least 1, so the make will always be called. I think we can skip the if and simply always call the lbls = make...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted cap 🤦‍♂️

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or just remove all of this and just reset lbls at the beginning of the for body, then append will take care of growing the array when needed

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wanted to reuse the arr. Fixed now

@bwplotka bwplotka force-pushed the sharding branch 2 times, most recently from 93e0515 to e4d81ef Compare February 24, 2020 11:16
Signed-off-by: Bartlomiej Plotka <bwplotka@gmail.com>
Copy link
Member

@brancz brancz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm on green

@bwplotka
Copy link
Member Author

At some point, we need benchmarks for those filters. Maybe we would need to make this more concurrently etc.

TODO: #2174

@brancz
Copy link
Member

brancz commented Feb 24, 2020

I assume you’re mostly talking about fetching the block meta. Relabeling is cheap, fast and cacheable.

@bwplotka
Copy link
Member Author

No, I mean filtering itself. Especially the graph-based one for duplicated blocks (: And yes, relabelling is maybe cacheable but we don't do that, do we? =D Anyway, added issue with help wanted - would be nice to have.

@bwplotka bwplotka merged commit 9f059f4 into master Feb 24, 2020
@bwplotka bwplotka deleted the sharding branch February 24, 2020 11:36
@brancz
Copy link
Member

brancz commented Feb 24, 2020

Makes sense.

vankop pushed a commit to monitoring-tools/thanos that referenced this pull request Feb 28, 2020
Signed-off-by: Bartlomiej Plotka <bwplotka@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants