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

compactor: Consider upper bound of block size #2340

Closed
bwplotka opened this issue Mar 30, 2020 · 17 comments
Closed

compactor: Consider upper bound of block size #2340

bwplotka opened this issue Mar 30, 2020 · 17 comments

Comments

@bwplotka
Copy link
Member

bwplotka commented Mar 30, 2020

Hi 👋

With vertical/offline deduplication we have a risk of oversized blocks. In the current design, this comes with the tradeoff of more difficult debug as well as at some point slower lookup.

From my experience chunk file size does not matter, but the index size matter, so we might want to split blocks at a certain size. Question is.. what size (: (most likely configurable). Thoughts? @brancz @SuperQ @pracucci @pstibrany

@pracucci
Copy link
Contributor

I'm probably missing some context. Is your plan to just split the result of compaction to multiple blocks or to shard blocks before running the compaction? I guess the first one, but I would prefer to avoid any misunderstanding from my side.

@bwplotka
Copy link
Member Author

I think actually something between. Do that during compaction (:

@bwplotka
Copy link
Member Author

bwplotka commented Mar 30, 2020

I am already exploring iterator interface on Prometheus side which could help with this

@pracucci
Copy link
Contributor

pracucci commented Mar 30, 2020

This will leave still open the vertical scalability limit of a compactor, until blocks can't be sharded. What I mean is, if compacting blocks for the range X takes more time than X you have a scalability limit. Wouldn't blocks sharding in the compactor solve both?

Ignore this comment. Was a misunderstand from my side. This is blocks sharding agnostic.

@stale
Copy link

stale bot commented Apr 29, 2020

Hello 👋 Looks like there was no activity on this issue for last 30 days.
Do you mind updating us on the status? Is this still reproducible or needed? If yes, just comment on this PR or push a commit. Thanks! 🤗
If there will be no activity for next week, this issue will be closed (we can always reopen an issue if we need!). Alternatively, use remind command if you wish to be reminded at some point in future.

@stale stale bot added the stale label Apr 29, 2020
@bwplotka
Copy link
Member Author

bwplotka commented Apr 29, 2020 via email

@stale stale bot removed the stale label Apr 29, 2020
@stale
Copy link

stale bot commented May 29, 2020

Hello 👋 Looks like there was no activity on this issue for last 30 days.
Do you mind updating us on the status? Is this still reproducible or needed? If yes, just comment on this PR or push a commit. Thanks! 🤗
If there will be no activity for next week, this issue will be closed (we can always reopen an issue if we need!). Alternatively, use remind command if you wish to be reminded at some point in future.

@stale stale bot added the stale label May 29, 2020
@stale
Copy link

stale bot commented Jun 5, 2020

Closing for now as promised, let us know if you need this to be reopened! 🤗

@stale stale bot closed this as completed Jun 5, 2020
@ipstatic
Copy link
Contributor

I think this is still relevant.

@SuperQ
Copy link
Contributor

SuperQ commented Jun 27, 2020

Yes, I just had a 480GB compaction, which means I need 1T of local disk to handle these events. It would be nice to be able to set an upper bound on TSDB block sizes.

@squat squat removed the stale label Jan 25, 2021
@squat
Copy link
Member

squat commented Jan 25, 2021

still relevant

@stale
Copy link

stale bot commented Apr 18, 2021

Hello 👋 Looks like there was no activity on this issue for the last two months.
Do you mind updating us on the status? Is this still reproducible or needed? If yes, just comment on this PR or push a commit. Thanks! 🤗
If there will be no activity in the next two weeks, this issue will be closed (we can always reopen an issue if we need!). Alternatively, use remind command if you wish to be reminded at some point in future.

@stale stale bot added the stale label Apr 18, 2021
@bwplotka
Copy link
Member Author

@Biswajitghosh98 is on it (:

@stale
Copy link

stale bot commented Jun 20, 2021

Hello 👋 Looks like there was no activity on this issue for the last two months.
Do you mind updating us on the status? Is this still reproducible or needed? If yes, just comment on this PR or push a commit. Thanks! 🤗
If there will be no activity in the next two weeks, this issue will be closed (we can always reopen an issue if we need!). Alternatively, use remind command if you wish to be reminded at some point in future.

@stale stale bot added the stale label Jun 20, 2021
@stale
Copy link

stale bot commented Jul 8, 2021

Closing for now as promised, let us know if you need this to be reopened! 🤗

@stale stale bot closed this as completed Jul 8, 2021
@yeya24 yeya24 reopened this Jul 8, 2021
@stale stale bot removed the stale label Jul 8, 2021
@stale
Copy link

stale bot commented Sep 6, 2021

Hello 👋 Looks like there was no activity on this issue for the last two months.
Do you mind updating us on the status? Is this still reproducible or needed? If yes, just comment on this PR or push a commit. Thanks! 🤗
If there will be no activity in the next two weeks, this issue will be closed (we can always reopen an issue if we need!). Alternatively, use remind command if you wish to be reminded at some point in future.

@stale stale bot added the stale label Sep 6, 2021
@stale
Copy link

stale bot commented Sep 22, 2021

Closing for now as promised, let us know if you need this to be reopened! 🤗

@stale stale bot closed this as completed Sep 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants