Redis 4.0 RC1 is out
antirez.com
Redis 4.0 RC1 is out
1–10 of 30 posts
Re: Redis 4.0 RC1 is out
#2The new LRU algorithm (which he calls Last Frequently Used) is in this release.
I really enjoyed the blog post on it when it was developed [0].
Very cool to see a real-word pragmatic solutions to this common/hard problem developed in the open (and in a very readable code-base). I've read through it thinking about my own LRU use in my own applications!
There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton
Re: Redis 4.0 RC1 is out
#3"Redis Cluster is now NAT / Docker compatible."
Yeehaw!!!!!!!
Re: Redis 4.0 RC1 is out
#4Very excited to see what the community creates with the new module system. Have to imagine we will see very specific, high performance database and cache systems built on top of the rock solid core that is Redis.
Re: Redis 4.0 RC1 is out
#5> There are reasons why UNLINK is not the default for DEL. I know things… I can’t talk.
Doesn't inspire confidence
Re: Redis 4.0 RC1 is out
#6The new LRU algorithm (which he calls Last Frequently Used) is in this release. I really enjoyed the blog post on it when it was developed [0]. Very cool to see a real-word pragmatic solutions to this common/hard problem developed in the open (and in a very readable code-base). I've read through it thinking about my own LRU use in my own applications! There are only two hard things in Computer Science: cache invalida…
There are only two hard things in Computer Science: cache invalidation, naming things, and off by one.
Re: Redis 4.0 RC1 is out
#7I just started developing a redis module to use SQLite in redis[1].
Overall it is a great experience, I find the module interface really well done and extremely powerful.
I already saw other greats modules around and I can't wait to see what the community will be able to come up with.
Re: Redis 4.0 RC1 is out
#8"Redis Cluster is now NAT / Docker compatible." Yeehaw!!!!!!!
Does it now let you replicate shards so you don't need to run slaves?
Re: Redis 4.0 RC1 is out
#9 antirez in commit 9d52411:
Update linenoise to fix insecure redis-cli history file creation.
1 file changed, 6 insertions(+), 1 deletion(-)
Re: Redis 4.0 RC1 is out
#10> There are reasons why UNLINK is not the default for DEL. I know things… I can’t talk. Doesn't inspire confidence
Ok I'll talk ;-) The matter is that currently, if you delete a key, you know that the command returns once the memory is reclaimed. UNLINK is conceptually like DEL, but the memory reclaiming, while fast because there is a thread doing only like that, is asynchronous. So in certain use cases, while semantically identical if you think at what happens to data, the two commands are semantically different in the way memory is reclaimed. Think at this:
1. CREATE A HUGE KEY.
2. DEL it
3. CREATE A HUGE KEY.
4. DEL it
In steps 2 and 4 we know that we always reclaim the memory if we use DEL, so step 3 is never going to use more memory than it was used in step 1. Instead change this with UNLINK. Potentially UNLINK is still freeing memory as we now create back the key again, technically using more memory than the previous peak memory.
This in practice is hard to trigger since asynchronous deleting is faster than the time it gets you to build new sizable data. But I still thought this was an important difference that deserved a different command name.