perf(blooms): Remove compression of .tar archived bloom blocks

[chaudum]

What this PR does / why we need it:

Decompression is a CPU intensive task, especially un-gzipping. The gain of compressing a tar archive of storage optimized binary blocks is neglectable (question: is it?).

In this example, the block of ~170MiB is ~3.3MiB bigger when not compressed, which is a ratio of ~2%

$ ls -las 2bc017f79711e12a-2bffc5dcc0e8e964_1726004114913-1726106283939-bc42f529.tar   
177048 -rw-rw-r-- 1 christian christian 181293056 Sep 18 13:49 2bc017f79711e12a-2bffc5dcc0e8e964_1726004114913-1726106283939-bc42f529.tar

$ ls -las 2bc017f79711e12a-2bffc5dcc0e8e964_1726004114913-1726106283939-bc42f529.tar.gz
173732 -rw-rw-r-- 1 christian christian 177897689 Sep 18 13:49 2bc017f79711e12a-2bffc5dcc0e8e964_1726004114913-1726106283939-bc42f529.tar.gz

$ qalc '(181293056 - 177897689) / 1024/ 1024'
((181293056 − 177897689) / 1024) / 1024 ≈ 3.238074303

$ qalc '181293056 / 177897689'
181293056 / 177897689 ≈ 1.019086066

Breaking change

⚠️ This PR introduces a breaking change of yet unreleased code, because the key (suffix) of blocks on object storage change.

This is less of an issue, because there has not been a release of the new structured metatada blooms yet. Anyone using a Loki version from main after commit a2fbaa8 is affected.

Special notes for your reviewer:

CPU profile from a time period where blocks have been downloaded and extracted.

Further discussion:

Adding the correct file type extension as suffix to the key in object storage makes any change to compression a breaking change, unless the GetBlock() call tries multiple different keys with different suffixes. That could be a rather hacky option to keep backwards compatibility, but it also introduces more complexity in various areas whenever the Addr() of a BlockRef needs to be resolved.

Another option would be to additionally store the compression algorithm into the BlockRef struct.

Update

After some consideration, we decided to store the encoding of the bloom block in the BlockRef. This means, that the changes in this PR do not break compatibility with existing blocks compressed with gzip, although new blocks will not be compressed any more.
However, the PR adds support for different compression algorithms, such as gzip, snappy, lz4, flate, and zstd. Compression is not configurable yet.

Checklist

• Reviewed the CONTRIBUTING.md guide (required)
• Documentation added
• Tests updated
• Title matches the required conventional commits format, see here
  • Note that Promtail is considered to be feature complete, and future development for logs collection will be in Grafana Alloy. As such, feat PRs are unlikely to be accepted unless a case can be made for the feature actually being a bug fix to existing behavior.
• Changes that require user attention or interaction to upgrade are documented in docs/sources/setup/upgrade/_index.md
• For Helm chart changes bump the Helm chart version in production/helm/loki/Chart.yaml and update production/helm/loki/CHANGELOG.md and production/helm/loki/README.md. Example PR
• If the change is deprecating or removing a configuration option, update the deprecated-config.yaml and deleted-config.yaml files respectively in the tools/deprecated-config-checker directory. Example PR

[rfratto]

LGTM, just optional nits

[rfratto]

nit: Panic on a call to String makes me a bit nervous since String can be implicitly called by different standard library functions. Normally in cases like this I would return fmt.Sprintf("Encoding(%d)", e) so you can see the value.

But if you think the risk is low, it's fine to keep it like this 👍

[chaudum]

I reverted my change

[rfratto]

nit: newRefFrom is only called once, and it's to immediately pass the ref into newBlockRefWithEncoding; should the functions be combined?

[chaudum]

I did the separation of concerns and composition of the functions intentionally. No strong opinions, though.

[rfratto]

Yeah I don't feel strongly about it either, Let's keep what you did IMO