Personally, modules have been the thing I wanted most in redis for years, and it's been a delightful experience working on modules for the past months. I really think it's a game changer for redis and I can't wait to see where this will take it in the coming years.
Some modules that are already out there (full disclosure - I work at Redis Labs and I've developed a couple of those):
The 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
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.
I understood it as such. Don't let the humor-impared* cramp your style. I'm sure a double-digit percentage of Redis' success is the result of your excellent writing and the character it adds to the project.
*but you could always add a footnote to avoid conspiracy theories about the CIA's efforts to infiltrate your memory reclaiming strategy.
Maybe a new command like "DELSYNC" should be added that acts like the current DEL behavior, and in a future version DEL could be changed to act like UNLINK?
Async in Redis is the exception, so I don't think delsync is necessary. DELASYNC doesn't sound bad though, assuming the functionality is exactly the same, but async.
For what little my opinion matters, I agree it would be clearer if the name helped to indicate that the semantics are the same except it's just an asynchronous DEL. Better than relying on a reference to unix semantics, no?
Very 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.
Any links to the timeseries modules mentioned in the post? Have found some npm modules that wrap timeseries around the API, I think, but not any modules that are directly integrating with Redis.
Some modules that are already out there (full disclosure - I work at Redis Labs and I've developed a couple of those):
* redis-cell - a rate limiter module https://github.com/brandur/redis-cell
* Redis Graph - a graph DB with a subset of Cipher for querying. https://github.com/swilly22/redis-module-graph
* RediSeach - fast full-text search engine with fuzzy auto-suggest. https://github.com/RedisLabsModules/RediSearch
* redis-ml: Machine learning models as redis data types. https://github.com/RedisLabsModules/redis-ml
* redablooms - scalable bloom filters https://github.com/RedisLabsModules/redablooms
* Secondary indexes with a small subset of SQL for WHERE clauses. https://github.com/RedisLabsModules/secondary
* Time Series https://github.com/saginoam/RedisModuleTimeSeries
PS If you're interested in creating modules, we've started a community for module developers. https://groups.google.com/forum/#!forum/redis-module-devs