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
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.
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
Doesn't inspire confidence
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.
Otherwise people will assume something a lot worse is going on given how you phrased it.
antirez in commit 9d52411:
Update linenoise to fix insecure redis-cli history file creation.
1 file changed, 6 insertions(+), 1 deletion(-)
Yeehaw!!!!!!!
Antirez keeps adding features I didn't know I always needed (ok...wanted), while keeping the same performant core.