3 ms·
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
by wanderr 14y ago
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.