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

all keys in memory #23

Open
gra-moore opened this issue May 6, 2020 · 2 comments
Open

all keys in memory #23

gra-moore opened this issue May 6, 2020 · 2 comments

Comments

@gra-moore
Copy link
Collaborator

Badger talks about keys being in-memory when doing key only iteration "It is several order of magnitudes faster than regular iteration, because it involves access to the LSM-tree only, which is usually resident entirely in RAM"

Obviously at some point there isnt enough memory, but is there some strategy for having "all" keys in memory in the skiplist structure. See issue on key compression as well.

@Drawaes
Copy link
Owner

Drawaes commented May 7, 2020

The skiplist always is all memory. If we come up with a strategy for moving the values off to a value log then the skiplist will be able to be a lot larger before we require a flush.

@gra-moore
Copy link
Collaborator Author

Sure, but once it is flushed they are not in memory? I read the badger thing to mean that in general they tried to keep as many of the keys in memory at any one time, including after they have been flushed to disk.

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

No branches or pull requests

2 participants