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.

Have you tried just replacing redis' Lua dependency with LuaJIT yourself? LuaJIT 2.0 should be a drop-in replacement for Lua 5.1, it has the same headers and even builds the same way.

What kind of things are you using Lua scripting for? I've not had a need to solve any problems using it yet, so I'm really interested in hearing about case-studies in the wild.

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

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

While awkwardly worded, it's correct

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

is how I interpreted it, but it did require a second pass.

that's definitely the correct meaning indeed. The idea is to understand if users believe commercial support for Redis is valuable or not.

What you just clarified is a big improvement. "Would commercial support for Redis be useful to you?"

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.

It's not 100% what you want, but with 2.6 DUMP/RESTORE commands you can pretty much do a good deal of what Diskstore used to do inside your application.

Well also add to the mix a bit of RANDOMKEY plus OBJECT IDLETIME. If you want to know more reply to this message or write to the Redis ML and I'll provide some detail.

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!

Thank you :) We are getting an awesome amount of submissions for the survey, very very cool.

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.

How big are your datasets?

Could you please describe how this would be exposed to the user? Thanks.

I'm pretty sure op meant it in an humorous way.

I also think it's a weird non-feature. That's certainly the one item of the survey that made me tick.

The idea was just to make sure that after a "make" you get some warning if this is not the latest version of Redis. An upgrade is a cost, so maybe to get a warning before deploying may be a good thing after all.

Another simpler thing can just be redis-cli --latest to output the latest version of the Redis server.

The second one would be great. The first one would make the build process depend on having internet connection. It's a very annoying thing if you build your packages in isolation.

I think redis-cli --latest is surely the best way. It polls the redis server, tells the user. Then maybe redis-cli --latest update-cli could do the actual update ..

This feature exists at distro-level package managers. Why should Redis solve this as well?

I don't get it either. As I said, that's a non-feature.

In a typical production scenario, you deploy a specific version of Redis and you don't care if it's outdated or not. That's the tested and production-ready version at Company X.