-
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
chore(blooms)!: Introduce a new block schema (V3) #14038
Conversation
1378b11
to
854e418
Compare
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.
Nice, I was able to follow along here fairly well. I didn't spot any major issues, so my comments are mainly questions rather than anything blocking.
@@ -145,6 +145,11 @@ func (p *processor) processBlock(_ context.Context, bq *bloomshipper.CloseableBl | |||
return err | |||
} | |||
|
|||
// We require V3 schema | |||
if !schema.IsCurrentSchema() { | |||
return v1.ErrUnsupportedSchemaVersion |
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 noticed that processor.processTasks
aborts after the first task group where p.processTasksForDay
returns an error. Is that something we want to keep?
Especially with this most recent change, I believe that means if any of the existing blocks aren't the current schema version, then we don't process any of newer ones, even if they're valid.
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.
Yeah, good point. We could ignore incompatible blocks, rather than fail.
But for the sake of simplicity, I would cancel a request with the first incompatible block.
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.
Sounds good to me. If this turns out to be an issue in the future we can replace it with multierror instead of returning immediately.
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.
Looks good from my side, Salva might see something I don't
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.
LGTM 👏
@@ -46,6 +46,8 @@ func (b *BloomBlockBuilder) Append(bloom *Bloom) (BloomOffset, error) { | |||
} | |||
} | |||
|
|||
// version := b.opts.Schema.version |
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.
Can we remove this?
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.
yes
pkg/storage/bloom/v1/builder.go
Outdated
@@ -66,9 +66,21 @@ func (b BlockOptions) Encode(enc *encoding.Encbuf) { | |||
enc.PutBE64(b.BlockSize) | |||
} | |||
|
|||
// func NewDefaultBlockOptions(maxBlockSizeBytes, maxBloomSizeBytes uint64) BlockOptions { |
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.
remove?
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.
yes
// V2 supports single series blooms encoded over multiple pages | ||
// to accommodate larger single series | ||
V2 | ||
// V2 indicated schema for indexed structured metadata |
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.
// V2 indicated schema for indexed structured metadata | |
// V3 indicated schema for indexed structured metadata |
type Schema struct { | ||
version Version | ||
encoding chunkenc.Encoding | ||
nGramLength, nGramSkip uint64 |
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.
IIUC, we are going to remove this once we remove the ngrams, right? But we will keep V3
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.
Yeah, we will remove them later on
opts: opts, | ||
writer: writer, | ||
index: NewIndexBuilder(opts, index), | ||
blooms: NewBloomBlockBuilder(opts, blooms), | ||
}, nil | ||
} | ||
|
||
func (b *V2Builder) BuildFrom(itr iter.Iterator[SeriesWithBlooms]) (uint32, error) { | ||
func (b *V3Builder) BuildFrom(itr iter.Iterator[SeriesWithBlooms]) (uint32, error) { |
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.
We have two builders: the merge builder and the regular builder. But IIUC, we only use the BuildFrom
from the merge builder, right? If so, we should remove this method (in a separate PR probably).
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.
BuildFrom
is actually only used in tests for building "literal blooms".
|
||
type V2Builder struct { |
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.
Will we support building older versions of blocks? If not, does it make sense to keep V3Builder in case we add a V4Builder in the future? Or should we name this Builder right away and keep changing it as we add versions?
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.
At some point when the feature is GA, yes. For now we can make all changes to the V3Builder.
Got rid of backwards compatibility shenanigans and introduced a new version that includes the indexed fields. Signed-off-by: Christian Haudum <christian.haudum@gmail.com>
Signed-off-by: Christian Haudum <christian.haudum@gmail.com>
Signed-off-by: Christian Haudum <christian.haudum@gmail.com>
Signed-off-by: Christian Haudum <christian.haudum@gmail.com>
Signed-off-by: Christian Haudum <christian.haudum@gmail.com>
Signed-off-by: Christian Haudum <christian.haudum@gmail.com>
Signed-off-by: Christian Haudum <christian.haudum@gmail.com>
Signed-off-by: Christian Haudum <christian.haudum@gmail.com>
Signed-off-by: Christian Haudum <christian.haudum@gmail.com>
Signed-off-by: Christian Haudum <christian.haudum@gmail.com>
ea8a541
to
1eb3b56
Compare
What this PR does / why we need it:
A new schema version V3 for bloom blocks that is incompatible with old schemas.
It simplifies some parts of the code and makes the schema more extensible, laying the groundwork for indexing structured metadata fields into bloom filters.
Checklist
CONTRIBUTING.md
guide (required)feat
PRs are unlikely to be accepted unless a case can be made for the feature actually being a bug fix to existing behavior.docs/sources/setup/upgrade/_index.md
production/helm/loki/Chart.yaml
and updateproduction/helm/loki/CHANGELOG.md
andproduction/helm/loki/README.md
. Example PRdeprecated-config.yaml
anddeleted-config.yaml
files respectively in thetools/deprecated-config-checker
directory. Example PR