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

Add an alternative to DeleteVersions that leaves no garbage #324

Merged
merged 32 commits into from
Nov 12, 2020

Conversation

klim0v
Copy link
Contributor

@klim0v klim0v commented Nov 4, 2020

The beginning of this issue is that the DeleteVersions method leaves behind a lot of dirty information, which leads to an increase in storage used by the storage.

I first added a method to remove versions up to a certain height, and now I have expanded it to allow removal within a given range.

DeleteVersionsTo deletes all versions below the given height
@klim0v klim0v requested a review from erikgrinaker as a code owner November 4, 2020 08:14
tree_test.go Show resolved Hide resolved
@klim0v klim0v changed the title add MutableTree#DeleteVersionsTo feature Add an alternative to DeleteVersions that leaves no garbage Nov 4, 2020
@erikgrinaker
Copy link
Contributor

erikgrinaker commented Nov 5, 2020

Thanks for contributing! I see you're still making changes to this, and that there are a few linter issues. Let me know when it's ready for review! Also, maybe convert this to a draft until it's ready.

@klim0v
Copy link
Contributor Author

klim0v commented Nov 5, 2020

Thanks for contributing! I see you're still making changes to this, and that there are a few linter issues. Let me know when it's ready for review! Also, maybe convert this to a draft until it's ready.

I see linter crashing in CI / CD config, updated to 1.28 and added nosec tag to ignore
Error: Failed to run: Error: requested golangci-lint version 'v1.27' isn't supported: we support only v1.28.3 and later versions, Error: requested golangci-lint version 'v1.27' isn't supported: we support only v1.28.3 and later versions

I finished making changes, you can proceed to check! @erikgrinaker

@klim0v
Copy link
Contributor Author

klim0v commented Nov 5, 2020

Finished!

@klim0v
Copy link
Contributor Author

klim0v commented Nov 5, 2020

@erikgrinaker, I added an alternative, can you check both of them? klim0v/iavl@6933e53...82251d8

@klim0v
Copy link
Contributor Author

klim0v commented Nov 6, 2020

I also suggest to mark the DeleteVersions method as deprecated and try to pass sorted versions from it to the DeleteVersionsInterval.

@klim0v
Copy link
Contributor Author

klim0v commented Nov 6, 2020

I also suggest to mark the DeleteVersions method as deprecated and try to pass sorted versions from it to the DeleteVersionsInterval.

@alexanderbez, how do you like it?

@erikgrinaker
Copy link
Contributor

erikgrinaker commented Nov 6, 2020

I've backported a bunch of linter fixes from master, so you can rebase to avoid all of the linter stuff.

I'd be interested to find out exactly what this garbage you see left behind by DeleteVersions actually is. We have a test TestRandomOperations that runs randomized operations against a tree and checks invariants, including calling DeleteVersion on all versions in random order, and in #326 I've added a test to make sure there are no stray database entries left behind at the end. It doesn't leave any garbage.

Since DeleteVersions basically just iterates over all versions and calls DeleteVersion, this should be equivalent to what this test does, and it doesn't produce any garbage in the database. Can you elaborate?

mergify bot pushed a commit that referenced this pull request Nov 6, 2020
Checks that we don't leave behind any junk in the database, as reported in #324.
@erikgrinaker
Copy link
Contributor

Ok, great - did it help with the performance though? I suspect using Range and calling Seek() are basically the same thing, thus it shouldn't have an effect on performance, but would be good to verify.

@klim0v
Copy link
Contributor Author

klim0v commented Nov 9, 2020

Ok, great - did it help with the performance though? I suspect using Range and calling Seek() are basically the same thing, thus it shouldn't have an effect on performance, but would be good to verify.

Yes, it helped! Now I'm looking for an explanation of why this happened.

@klim0v
Copy link
Contributor Author

klim0v commented Nov 9, 2020

I suppose Seek() could be slow due to the need to go through the entire tree to make sure there is no such key.

@erikgrinaker
Copy link
Contributor

Great! It may be that Seek() actually iterates. Either way, want to submit a PR for tm-db?

@klim0v klim0v requested a review from erikgrinaker November 9, 2020 12:52
@klim0v
Copy link
Contributor Author

klim0v commented Nov 9, 2020

Great! It may be that Seek() actually iterates. Either way, want to submit a PR for tm-db?

Yes, but I can't yet confirm my words with performance tests to describe this problem...

Copy link
Contributor

@erikgrinaker erikgrinaker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR includes a bunch of noisy formatting changes, it would be nice to avoid these since they're unrelated to the main change.

Also, I've released new versions of tm-db and updated the 0.15 and 0.14 branches of IAVL.

mutable_tree.go Outdated Show resolved Hide resolved
tree_random_test.go Outdated Show resolved Hide resolved
@klim0v
Copy link
Contributor Author

klim0v commented Nov 10, 2020

This PR includes a bunch of noisy formatting changes, it would be nice to avoid these since they're unrelated to the main change.

Also, I've released new versions of tm-db and updated the 0.15 and 0.14 branches of IAVL.

Done ✅

@klim0v klim0v requested a review from erikgrinaker November 10, 2020 16:47
@erikgrinaker erikgrinaker self-assigned this Nov 11, 2020
Copy link
Contributor

@erikgrinaker erikgrinaker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great stuff, thank you for this! Suggested a few minor nitpicks, otherwise LGTM!

mutable_tree.go Outdated Show resolved Hide resolved
tree_random_test.go Outdated Show resolved Hide resolved
tree_random_test.go Outdated Show resolved Hide resolved
CHANGELOG.md Outdated Show resolved Hide resolved
@klim0v
Copy link
Contributor Author

klim0v commented Nov 11, 2020

I have added your recommendations, thanks!

@erikgrinaker erikgrinaker merged commit 9af2c83 into cosmos:0.14.x Nov 12, 2020
KamiD added a commit to okblockchainlab/iavl that referenced this pull request Apr 10, 2021
* fix: constant overflow when compiling for 32bit machines (cosmos#318)

on Go 1.x(x) all constants are ints by default which causing
build for 32bit machines to fail due to overflow
golang/go#23086

Signed-off-by: Artur Troian <[email protected]>

* changelog: release 0.14.2

* lint: update golangci-lint to 1.29 (cosmos#297)

* ci: freeze golangci action version (cosmos#303)

* github: bump golangci-lint and fix linter issues (cosmos#325)

* test: check stray database entries in TestRandomOperations (cosmos#326)

Checks that we don't leave behind any junk in the database, as reported in cosmos#324.

* revert Protobuf methods accidentally cherry-picked in a41e36b

* go.mod: bump tm-db to 0.5.2

* fix DeleteVersions stray orphans, and add DeleteVersionsRange (cosmos#324)

* test: add TestRandomOperations case for DeleteVersions

* test: run slow tests without race detector in CI (cosmos#338)

* changelog: release 0.14.3 (cosmos#333)

Co-authored-by: Artur Troian <[email protected]>
Co-authored-by: Erik Grinaker <[email protected]>
Co-authored-by: Marko <[email protected]>
Co-authored-by: Klimov Sergey <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants