

The Redis Community Survey - j4mie
http://antirez.com/post/redis-community-survey.html

======
wanderr
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.

------
pjscott
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.

~~~
pjin
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.

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

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

~~~
jimktrains2
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.

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

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

------
iamjustlooking
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.

~~~
antirez
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.

------
spenrose
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!

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

------
bsg75
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.

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

~~~
bsg75
How big are your datasets?

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

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

~~~
nakkiel
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.

~~~
antirez
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.

~~~
primitur
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 ..

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

~~~
nakkiel
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.

