

Is Redis a noSQL db, a cache, or a messaging server? - akkartik
http://antirez.com/post/redis-weekly-update-3-publish-submit.html

======
sketerpot
This needs repeating:

> This is how it is possible to write modular, scalable applications today:
> you need a very fast "global state" (the DB side), caching, ways to create
> queues of jobs as soon or later you need to process things in the
> background, and sometimes you need the ability to pass messages around in a
> pub/sub many-to-many scenario. And this things are converging, they are just
> different sides of the same things, at least when the DB part is designed as
> it is in Redis.

~~~
mcs
With Redis, memcached finally has a contender for most awesome cache... thing.
However I'm surprised I don't see more benchmarks. Performance should be
roughly the same unless there's huge I/O contention for persistent storing.

~~~
dlsspy
I'm a bit biased, but I'm not as optimistic as some.

memcached had a design similar to redis when I first got involved with it a
few years ago. It was fine for a lot of systems, but didn't scale to the
larger ones. It took a lot of work for us to get it to the point where it
could saturate all of the cores you could give it.

If anyone can ever produce a benchmark where memcached does not perform better
than redis, please file a bug in memcached, or at the very least, start a
conversation.

The closest I've seen were tests that degraded to client tests. In one case,
someone took a _very_ poorly performing memcached client and compared it
against a _very_ well-tuned redis client and a couple of relational databases
and showed that memcached was the slowest of all. _sigh_

In most of these cases, the test environments perform at the very least an
order of magnitude slower than what I get on my development laptop (I have no
trouble sustaining 90k writes per second with either of a simple c++ thing I
threw together yesterday or my high level java client).

On real production-quality machines with good networks, 300-400k ops per
second isn't hard to achieve. Even between two old "large" (2 core, 7GB) EC2
nodes, I've been doing 90k ops per second all day (which is somewhere around
the point where they start to throttle my bandwidth).

~~~
antirez
Hello dlsspy, I never tested memcached, but I'm really sure about Redis
numbers: you can get 150k ops/sec in a decent Linux box without problems, _per
core_. So if you got 4 cores you can get 600k ops/sec, assuming you'll have
enough bandwidth to saturate that.

I agree with you that if Redis performance is better than memcached there is
to fill a bug or start a conversation, as there is something odd. Both are
written in C and use multiplexing internally, against the same OSes. The
performances should be very similar, or the memcached performances should be
better as it supports less features.

Edit: p.s. can you please explain why running multiple memcached processes,
one per core, was not good enough?

~~~
dlsspy
I'm certainly not trying to start a fight or anything, but there's a lot of
bad testing out there, and people like trumpeting the results of such things.

Having more machines reduces the performance gained from multigets. This is
often a pretty big performance boost. This is especially useful with
synchronous clients that serialize requests across servers (which are very
common in many popular languages because popular languages don't seem to
encourage proper concurrency). Four times the number of servers will quite
often make requests take four times longer.

Some of the memcached clients will do additional work to hash the keys using
an independent node location key just to ensure locality of related data so
the values can be retrieved more efficiently.

~~~
antirez
Sure, many tests are conducted in a wrong way, I fully agree.

About multi-gets, this is how Redis handle this, we have a concept called key
tags, that I think it is very similar to the one you described. Basically a
key in the form foo{bar} gets hashed in a special way, only the part inside {}
is hashed ('bar' in my example).

So a client willing to optimize for multi get will use {user0}:name
{user0}:surname and so forth. Well, not the perfect example as with Redis in
this specific case you could use an Hash that is much more space efficient and
will provide locality of related keys automatically.

------
mmaunder
It's not a cache because memcache is already all the cache we need. Not sure
why you mention messaging server unless you're expecting listeners to poll the
server instead of get told about events. So I think it's a noSQL DB.

For my practical uses I'm most interested in Redis as a backing store for
distributed persistent redundant key-value stores like:

<http://kumofs.sourceforge.net/> <http://opensource.plurk.com/LightCloud/>

And my requirements are: 1\. Speed. Gobs of it. Ridiculous amounts of speed.
2\. Data must get written to disk periodically and I don't care if you lose a
few minutes worth when I lose a disk. I'd like some control over how much data
I'm prepared to lose vs speed. 3\. O(log N) scalability. 4\. More interesting
ways to sort, extract, modify and delete data stored in a key or multiple keys
without impacting performance.

Thanks Salvatore for your hard work!!

~~~
jasonwatkinspdx
"It's not a cache because memcache is already all the cache we need."

That's quite the display of logical thought there. Rottweilers aren't dogs
because black labs are all the dog we need.

