The Redis Community Survey

I didn't end up filling out the survey because all of the questions are oriented towards how we currently use redis, to which the answer is "barely, almost not at all" even though there is huge potential for us to use it in the future. Since I know antirez keeps up with these discussions on HN, I'll leave my feedback here instead. ;)

We used redis for some really intensive stuff for a short while at Grooveshark, but we were bitten by some really nasty issues related to writing data to disk and handling getting over the amount of memory available (redis was using 2x amount of memory needed for data every time it wrote the data set to disk because of broken copy-on-write)...those issues have long since been solved, but by the time they had been, we had thoroughly tested and switched over to mongo.

We haven't had the time to re-evaluate modern redis or the inclination to switch back since mongo is working OK for the most part, but I really do miss the advanced data structures and the atomic operations that can be performed on them, so I'd love to see us switch back some day.

The things I'd love to see in redis (keep in mind I haven't kept up with redis so some of these may already be there) are: -master/slave replication -sharding -automatic failover like mongo/mongos -ability to store more data than fits in memory, with a sane degredation in performance when data not-in-memory is being accessed, rather than just going into swap death -a way to write out data to disk without blocking/locking the whole server even when we're talking about 80+GB of data/RAM -the ability to start redis with a large data set in a predictable/sane period of time -memcached style psuedo-LRU eviction so redis can be used as a cache

again, no offense intended if these things are already in there and working well, this is just what we'll be looking at if/when it comes time to re-evaluate our "nosql" storage solution.

I use Redis' Lua scripting pretty heavily, because it's amazingly useful, and here are the features I would like most:

1. LuaJIT. The extra speed would open up a lot of new possibilities for doing fancy things with Lua scripting. A big enough quantitative difference in speed is a qualitative difference.

2. The ability to add on third-party libraries. The modules that come out of the box are great, but there's a lot of other good code out there.

3. More convenient ways of writing a logging statement than redis.log(redis.LOG_DEBUG, "Hello, world!"). I end up needing to look up the syntax for that one more often than I'd like to admit.

Finally, a request that doesn't involve Lua: several times, it would have been very convenient to be able to iterate through all the keys in a Redis database in constant space. The "KEYS *" command doesn't stream keys; it buffers them up, which may explode on large databases. My alternate approach was to parse the RDB dump file offline, but that's tricky and kind of slow with the tools that exist now.

> 20. Would a Redis support offering you pay for be useful to you?

I think they mean, "Would you pay for Redis support?"

I would love to see redis diskstore back. I haven't found a disk based LRU cache that persists to disk that is as easy as the diskstore was.

On many of the questions I gave relatively conservative answers because more aggressive Redis use is in the planning stages.

I love Redis because it has helped me replace intra-process concurrency with inter-process concurrency, which I feel is a superior model for the problems I'm trying to solve. Thank you so very much!

My answers were based on planned future use, as it is still experimental in my projects.

Hopeful some form of VM will return in the future, more for handling bursts than for long term storage.

I would have to go for official Redis HA support. Restart time is painful when your Redis instance is large.

A self-updating feature in redis-cli? Sure, why not. All the cool kids are doing it .. (=>in: 2007) ;)