Is memcached a dinosaur in comparison to Redis?

I have worked quite a bit with memcached the last weeks and just found out about Redis. When I read this part of their readme, I suddenly got a warm, cozy feeling in my stomach:

> Redis can be used as a memcached on steroids because is as fast as > memcached but with a number of > features more. > Like memcached, Redis also supports setting timeouts to keys so > that this key will be automatically > removed when a given amount of time > passes.

This sounds amazing. I'd also found this page with benchmarks: http://www.ruturaj.net/redis-memcached-tokyo-tyrant-mysql-comparison

So, honestly - Is memcache really that old dinousaur that is a bad choice from a performance perspective when compared to this newcomer called Redis?

I haven't heard lot about Redis previously, thereby the approach for my question!

Depends on what you need, in general I think that:

• You should not care too much about performances. Redis is faster per core with small values, but memcached is able to use multiple cores with a single executable and TCP port without help from the client. Also memcached is faster with big values in the order of 100k. Redis recently improved a lot about big values (unstable branch) but still memcached is faster in this use case. The point here is: nor one or the other will likely going to be your bottleneck for the query-per-second they can deliver.
• You should care about memory usage. For simple key-value pairs memcached is more memory efficient. If you use Redis hashes, Redis is more memory efficient. Depends on the use case.
• You should care about persistence and replication, two features only available in Redis. Even if your goal is to build a cache it helps that after an upgrade or a reboot your data are still there.
• You should care about the kind of operations you need. In Redis there are a lot of complex operations, even just considering the caching use case, you often can do a lot more in a single operation, without requiring data to be processed client side (a lot of I/O is sometimes needed). This operations are often as fast as plain GET and SET. So if you don't need just GET/SET but more complex things Redis can help a lot (think at timeline caching).

Without an use case is hard to pick the right now, but I think that for a lot of things Redis makes sense since even when you don't want to use it as a DB, being a lot more capable you can solve more problems, not just caching but even messaging, ranking, and so forth.

P.s. of course I could be biased since I'm the lead developer of the Redis project.

> So, honestly - Is memcache really that > old dinousaur that is a bad choice > from a performance perspective when > compared to this newcomer called > Redis?

• Comparing features set then Redis has way more functionality;
• Comparing ease of installation Redis is also a lot easier. No dependencies required;
• Comparing active development Redis is also better;
• I believe memcached is a little bit faster than Redis. It does not touch the disc at all;
• My opinion is that Redis is better product than memcached.

Memcache is an excellent tool still and VERY reliable.

instead of looking at this issue from the perspective getting down the who is faster at the < 100 ms range, look at the performance per "class" of the software.

• Does it use only local ram? -> fastest
• Does it use remote ram? -> fast
• Does it use ram plus hardddisk -> oh hurm.
• Does it use only harddisk -> run!

What memcached does that Redis doesn't do is least-recently-used eviction of values from the cache. With memcached, you can safely set as many values as you like, and when they overflow memory, the ones you haven't used recently will be deleted. With Redis, you can only approximate this, by setting a timeout on everything; when it needs to free up memory, it will look at three random keys and delete the one that's the closest to expiring.

That's the main difference, if you're just using it as a cache.

You may also want to look at Membase.

http://www.northscale.com/products/membase_server.html

I have not used it, but it appears to be similar to Redis in that it is a memory-centric KV store with persistence. The major differences from what I can see are:

• Redis has significantly more data manipulation capability (ordered sets, etc.)

• Redis has a pending Redis Cluster project to add horizontal scalability

• Redis has a single tier of data offload to disk (VM) based on a hybrid algorithm that considers both LRU and the size of the object.

• Membase uses the memcached wire protocol - useful as an upgrade path for existing applications

• Membase is set up to scale horizontally using a distributed hashtable approach

• Membase can support multiple tiers of data offload using an LRU approach (very seldom used goes to disk, somewhat seldom stuff goes to SSD, frequent stuff stays in RAM)

• Not sure about TTL capability in Membase.

The choice may depend on the degree to which your application can leverage the extra data manipulation functionality in Redis.

Hazelcast supports the memcached protocol natively

https://web.archive.org/web/20140601010929/http://hazelcast.org/docs/latest/manual/html-single/hazelcast-documentation.html

and thus is a modern alternative to memcached. You should try all the solutions to see what works best for you.