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

[DocDB] Merge empty tablets #21816

Open
1 task done
FranckPachot opened this issue Apr 4, 2024 · 0 comments
Open
1 task done

[DocDB] Merge empty tablets #21816

FranckPachot opened this issue Apr 4, 2024 · 0 comments
Assignees
Labels
area/docdb YugabyteDB core features kind/enhancement This is an enhancement of an existing feature priority/medium Medium priority issue

Comments

@FranckPachot
Copy link
Contributor

FranckPachot commented Apr 4, 2024

Jira Link: DB-10716

Description

When data is deleted and leave empty tablets, they stay empty, using CPU and RAM. If they are on a key that is always increasing, like a primary key from a sequence or an index on a timestamp, they will never be used again by new rows.
During the lifecycle of an SQL application, such tables will grow, and then be automatically split, and old data will be deleted. This can result to an always increasing number of tablets.

It would be great that such tablets are merged to leave at most one empty tablet. This can be manual as it usually result from purge or archiving of data.

See https://yugabyte.slack.com/archives/C4K1838GL/p1711987353340979?thread_ts=1711798545.131779&cid=C4K1838GL

Workaround: use declarative partitioning on top to be able to drop an empty partition when it has all empty tablets, but this brings back the PostgreSQL partitioning limitations (no global indexes) that we don't have with sharding

If REINDEX CONCURRENTLY was supported, for primary key and secondary indexes, it would also be a workaround as this operation doesn't need to be frequent #10694

Issue Type

kind/enhancement

Warning: Please confirm that this issue does not contain any sensitive information

  • I confirm this issue does not contain any sensitive information.
@FranckPachot FranckPachot added area/docdb YugabyteDB core features status/awaiting-triage Issue awaiting triage labels Apr 4, 2024
@yugabyte-ci yugabyte-ci added kind/enhancement This is an enhancement of an existing feature priority/medium Medium priority issue labels Apr 4, 2024
@yugabyte-ci yugabyte-ci removed the status/awaiting-triage Issue awaiting triage label Apr 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/docdb YugabyteDB core features kind/enhancement This is an enhancement of an existing feature priority/medium Medium priority issue
Projects
None yet
Development

No branches or pull requests

3 participants