Skip to content

feat(store)!: order-preserving varint key encoding#1764

Closed
melekes wants to merge 13 commits intomainfrom
anton/1041-order-preserving-key-encoding
Closed

feat(store)!: order-preserving varint key encoding#1764
melekes wants to merge 13 commits intomainfrom
anton/1041-order-preserving-key-encoding

Conversation

@melekes
Copy link
Collaborator

@melekes melekes commented Dec 7, 2023

uses the orderedcode library to lexicographically encode the key's in the state store, block store, evidence pool and light store.

Port of tendermint/tendermint#5771

Closes #1041


PR checklist

  • Tests written/updated
  • Changelog entry added in .changelog (we use unclog to manage our changelog)
  • Updated relevant documentation (docs/ or spec/) and code comments

Co-authored-by: Callum Waters <cmwaters19@gmail.com>
@melekes melekes self-assigned this Dec 7, 2023
@melekes melekes changed the title store: order-preserving varint key encoding feat!(store): order-preserving varint key encoding Dec 12, 2023
@github-actions
Copy link

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale For use by stalebot label Dec 23, 2023
@jmalicevic jmalicevic added wip Work in progress and removed stale For use by stalebot labels Dec 25, 2023
@melekes melekes changed the title feat!(store): order-preserving varint key encoding feat(store)!: order-preserving varint key encoding Jan 31, 2024
@melekes melekes mentioned this pull request Jan 31, 2024
3 tasks
@melekes
Copy link
Collaborator Author

melekes commented Jan 31, 2024

The migration script needs to be copied and adapted from #1814.

@mzabaluev
Copy link
Contributor

Would this include a fix for #1857?

@jmalicevic
Copy link
Collaborator

Would this include a fix for #1857?

That is a separate concern I believe.

@melekes melekes deleted the anton/1041-order-preserving-key-encoding branch February 14, 2024 12:48
return height, nil
}
itr.Next()
if itr.Valid() {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Implementing this for the other PR. This should return the height if there is no error. Otherwise, there might be a reason for the error where we should keep iterating. In the new layout I think it is these two conditions

		err = fmt.Errorf("expected light block prefix but got: %d", lightBlockPrefix)
	}
	if dbPrefix != storePrefix {
		err = fmt.Errorf("parsed key has a different prefix. Expected: %s, got: %s", storePrefix, dbPrefix)
	}
	
	

And in the old one it is the first condition when there is no submatch.

github-merge-queue bot pushed a commit that referenced this pull request Mar 15, 2024
Closes #2057 , #1041

If we keep the current design, we are also closing
#1822

Supersedes #1764 

This PR implements support for an additional DB key representation. The
different key layout sorts the entries by height instead of
lexicographically as in the current version of Comet.

When starting this work, we hoped that the new layout would
significantly outperform the current layout. As we do not have
sufficient real world evidence for this, this PR introduces a DB key
layout interface that would allow Comet to easily integrate a more
preferential key representation without major breaking changes.

The layout using ordercode is introduced as experimental, allowing users
to easily experiment with this.

This layout was thoroughly tested as part of #1044 and all results will
be in a report closing the mentioned PR.
 
Locally tested:
- Empty stores get initialized with v2
- Existing stores without a version key get initialized to v1 and the
key is set
- When a nodes' stores are deleted and we boot it up again that node
uses v2 while the rest of the nodes use v1
<!--

Please add a reference to the issue that this PR addresses and indicate
which
files are most critical to review. If it fully addresses a particular
issue,
please include "Closes #XXX" (where "XXX" is the issue number).

If this PR is non-trivial/large/complex, please ensure that you have
either
created an issue that the team's had a chance to respond to, or had some
discussion with the team prior to submitting substantial pull requests.
The team
can be reached via GitHub Discussions or the Cosmos Network Discord
server in
the #cometbft channel. GitHub Discussions is preferred over Discord as
it
allows us to keep track of conversations topically.
https://github.com/cometbft/cometbft/discussions

If the work in this PR is not aligned with the team's current
priorities, please
be advised that it may take some time before it is merged - especially
if it has
not yet been discussed with the team.

See the project board for the team's current priorities:
https://github.com/orgs/cometbft/projects/1

-->

---

#### PR checklist

- [x] Tests written/updated
- [x] Changelog entry added in `.changelog` (we use
[unclog](https://github.com/informalsystems/unclog) to manage our
changelog)
- [ ] Updated relevant documentation (`docs/` or `spec/`) and code
comments
- [x] Title follows the [Conventional
Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec

---------

Co-authored-by: Anton Kaliaev <anton.kalyaev@gmail.com>
mergify bot pushed a commit that referenced this pull request Mar 18, 2024
Closes #2057 , #1041

If we keep the current design, we are also closing
#1822

Supersedes #1764

This PR implements support for an additional DB key representation. The
different key layout sorts the entries by height instead of
lexicographically as in the current version of Comet.

When starting this work, we hoped that the new layout would
significantly outperform the current layout. As we do not have
sufficient real world evidence for this, this PR introduces a DB key
layout interface that would allow Comet to easily integrate a more
preferential key representation without major breaking changes.

The layout using ordercode is introduced as experimental, allowing users
to easily experiment with this.

This layout was thoroughly tested as part of #1044 and all results will
be in a report closing the mentioned PR.

Locally tested:
- Empty stores get initialized with v2
- Existing stores without a version key get initialized to v1 and the
key is set
- When a nodes' stores are deleted and we boot it up again that node
uses v2 while the rest of the nodes use v1
<!--

Please add a reference to the issue that this PR addresses and indicate
which
files are most critical to review. If it fully addresses a particular
issue,
please include "Closes #XXX" (where "XXX" is the issue number).

If this PR is non-trivial/large/complex, please ensure that you have
either
created an issue that the team's had a chance to respond to, or had some
discussion with the team prior to submitting substantial pull requests.
The team
can be reached via GitHub Discussions or the Cosmos Network Discord
server in
the #cometbft channel. GitHub Discussions is preferred over Discord as
it
allows us to keep track of conversations topically.
https://github.com/cometbft/cometbft/discussions

If the work in this PR is not aligned with the team's current
priorities, please
be advised that it may take some time before it is merged - especially
if it has
not yet been discussed with the team.

See the project board for the team's current priorities:
https://github.com/orgs/cometbft/projects/1

-->

---

#### PR checklist

- [x] Tests written/updated
- [x] Changelog entry added in `.changelog` (we use
[unclog](https://github.com/informalsystems/unclog) to manage our
changelog)
- [ ] Updated relevant documentation (`docs/` or `spec/`) and code
comments
- [x] Title follows the [Conventional
Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec

---------

Co-authored-by: Anton Kaliaev <anton.kalyaev@gmail.com>
(cherry picked from commit 55638e8)
melekes pushed a commit that referenced this pull request Mar 18, 2024
Closes #2057 , #1041

If we keep the current design, we are also closing
#1822

Supersedes #1764 

This PR implements support for an additional DB key representation. The
different key layout sorts the entries by height instead of
lexicographically as in the current version of Comet.

When starting this work, we hoped that the new layout would
significantly outperform the current layout. As we do not have
sufficient real world evidence for this, this PR introduces a DB key
layout interface that would allow Comet to easily integrate a more
preferential key representation without major breaking changes.

The layout using ordercode is introduced as experimental, allowing users
to easily experiment with this.

This layout was thoroughly tested as part of #1044 and all results will
be in a report closing the mentioned PR.
 
Locally tested:
- Empty stores get initialized with v2
- Existing stores without a version key get initialized to v1 and the
key is set
- When a nodes' stores are deleted and we boot it up again that node
uses v2 while the rest of the nodes use v1


---

#### PR checklist

- [x] Tests written/updated
- [x] Changelog entry added in `.changelog` (we use
[unclog](https://github.com/informalsystems/unclog) to manage our
changelog)
- [ ] Updated relevant documentation (`docs/` or `spec/`) and code
comments
- [x] Title follows the [Conventional
Commits](https://www.conventionalcommits.org/en/v1.0.0/) spec
<hr>This is an automatic backport of pull request #2327 done by
[Mergify](https://mergify.com).

Co-authored-by: Jasmina Malicevic <jasmina.dustinac@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

wip Work in progress

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Reconsider representation of keys for state and block store

4 participants