-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Bloom compactor: Load blocks lazily in batches #11919
Conversation
func newBatchedBlockLoader(ctx context.Context, fetcher blocksFetcher, blocks []bloomshipper.BlockRef) (*batchedBlockLoader, error) { | ||
return &batchedBlockLoader{ | ||
ctx: ctx, | ||
batchSize: 10, // make configurable? |
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 agree this should be configurable
err.Add(itr.CloseBatch()) | ||
default: | ||
// close remaining loaded blocks | ||
for itr.Next() && itr.Err() == nil { |
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.
Would we ever reach here? As far as I can see closeLoadedBlocks
is only called from buildBlocks
which will pass whatever loadWorkForGap
returns.
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.
Since the function accepts an interface v1.CloseableInterator[*bloomshipper.CloseableBlockQuerier]
and not a concrete type, it could be possible that a non-batched version of the iterator is passed.
Signed-off-by: Christian Haudum <[email protected]>
dafa7f0
to
35c21ac
Compare
…rs (grafana#11924) While reviewing grafana#11919, I figured it'd be nice to make `batchedLoader` generic so we can reuse it's logic. This let me test it easier and remove a lot of now-unnecessary adapter code (interfaces, types)
To avoid loading possibly lots of blocks upfront, this PR introduces lazy loading of blocks in batches using an iterator that loads blocks on demand. Signed-off-by: Christian Haudum <[email protected]>
What this PR does / why we need it:
To avoid loading possibly lots of blocks upfront, this PR introduces lazy loading of blocks in batches using an iterator that loads blocks on demand.
This is the first part of making the block loading truly lazy.
As a second part, the interface of the merge build is going to change so it accepts a single iterator.