-
Notifications
You must be signed in to change notification settings - Fork 199
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
feat: added LFU caching eviction with constant time operation #42
base: master
Are you sure you want to change the base?
Conversation
Looks good enough, but it would be better if some degree of concurrency safety is there. |
Our database is in-memory and this implementation is very heavy on memory requiring a lot of auxiliary data structures. We should try to reduce that even if we don't meet the correctness. |
Plus this is not CPU cache efficient. Keeping another copies of keys is also inefficient. |
@arpitbbhayani I agree, this implementation might be good for a cache(small set of values) but not for an in-mem database(a large set of values). As it increases the data movements(allocations) as well as it will pressurize the GC and "stop-the-world" problems with the CPU would arise. Have you found a suitable approximation algorithm for LFU? An approximate LFU algorithm is simple enough, please look at this @mrchocha |
Hey, I know it will add some new data structures. but not sure how can I reduce it. any suggestions? |
Ya, I thought it would be good if I can create it in plug and play manner. otherwise, I had to change the store object, and then every object will have a couple of extra variables that might not be used for other eviation policies. |
Read approximate counting - Morris counter and piggy back on LRU field we already have in our object struct. Research more on how it can be done while being more space efficient. Coding the solution is the easiest thing there. I would highly recommend you explore a bunch of approaches and papers to come up with the best solution. Key Pointers
Happy to discuss. |
Ya got some ideas from the articles like how it can be memory efficient. correct me if I am wrong.
here counter will be logarithmic/Morris and it's 8 bit so at max, we will have 256 nodes in the frequency list and need to decrease the counter after since we have like Redis uses this formula for counter |
@mrchocha there are a lot of gaps in your understanding. Would recommend spending some time understanding the approach well. Also, this is not the only way to do it. Research more on this. Would really recommend you read more papers and seek other approaches. It is okay if it takes time. Let's find a novel approach that would make Dice DB super-efficient. |
sure |
Let's keep dumping approached in #44 and use that space to converge on a solid approach. |
@mrchocha Thanks for the contribution. There are conflicts in this PR atm. |
context
Issue Link: #10
Reference Link: https://arpitbhayani.me/blogs/lfu
screenshots
SET operation
GET operation and Re-Balancing
DEL operation