Clarifications about Redis and Memcached

I dropped Memcached in favor of Redis for caching a <i>long</i> time ago, because as far as it matters for my purposes, Redis is a strictly-superior superset of Memcached&#x27;s functionality, and I have no desire to maintain multiple pieces of software in the stack if one will do the job.<p>I&#x27;m sure there are extreme cases where Memcached is in fact the better tool for the job over Redis for caching workloads. I also expect that 99%+ of people trying to decide between Redis and Memcached will never get into that territory. Redis is <i>so</i> fast that unless you&#x27;re doing O(n) operations on very large data sets, you&#x27;re unlikely to notice any substantial differences.<p>The other thing about caching is that the data is, by its nature, disposable and rebuildable. So even in the extreme minority case where Redis would no longer be sufficient, migration from one KV cache system to another is about as easy as it gets. Pre-optimizing your caching layer stack for Facebook levels of traffic isn&#x27;t even justifiable from a lock-in standpoint like it might be with other data storage needs.<p>In the case of your average Sidekiq user, serving cache fragments for a Rails app, memcached vs redis for your caching layer is almost certainly an inconsequential choice WRT the performance of your application, and the choice of Redis reduces your ops and client library overhead. The choice should be pretty clear in those circumstances.

This is a really good blog post. I find it very neutral even when the author happens to be the one who created Redis.<p>What I really like about both pieces of software is that they are dead simple to set up. If I were to make a decision today for new projects who are just starting to scale I&#x27;d probably take a good hard look at redis and see if you don&#x27;t need any of the extra features. I could see a lot of projects eventually needing those features and leveraging redis. I really like the pub&#x2F;sub feature in particular. Persistence is always nice if you don&#x27;t have to pay too much for it.<p>Does anyone know if amazon has a redis&#x2F;memcache service? I can never remember what they name things.

I&#x27;m curious about the &quot;threaded redis&quot; reference. Back a couple of years ago I built a Collaborative Filtering recommendation system that used Redis for graph storage and relied heavily on sorted sets to compute the recommendation right in Redis.<p>I <i>really</i> needed some kind of a parallelism and so I hacked together <a href="http:&#x2F;&#x2F;thredis.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;thredis.org&#x2F;</a> (and then mostly for fun added SQL operations to it by linking it with SQLite).<p>Since then I&#x27;ve kind of abandoned this project and moved on to other things, but I still think that there is a valid case for some form parallelism in Redis. I had learned some tough lessons while hacking on Thredis such as importance of ordering locks, having retry strategies, and there are still bugs that can cause it to crash AFAIK, but the take away was that it&#x27;s doable - I was a newbie at it, today I&#x27;d probably do a much better job. In my (not so scientific) testing Thredis was only slightly slower than Redis.

I tried both and i prefer Redis over Memcached except for very simple use cases. It is true that for a pure caching system Memcached is easier to setup, easier to scale and faster. But by just a small margin. On the opposite side, Redis provide a lot of primitive very fast and implemented in C that allow for more complex use cases. For instance, in one of the project I was following, the ability to merge two or more sorted set was pivotal in implementing a more efficient warm-up scheme. I could get the same result with Memcached and a software layer, but it would be less efficient in term of latency and bandwidth. Given these huge advantages, my choice is almost always Redis because I prefer to manage one system instead of two.

If data access is equally distributed across keys, then running multiple Redis instances (with sharding) is perfect, since ultimately you want each key to be serviced by a single core, for optimal performance in a system with caches and NUMAs.<p>However, if data access is read-heavy and not equally distributed across keys, then having shared memory (aka multithreading) is quite essential since you want all cores to operate on the same data, and shared memory is much better than sending the data across especially if the heavily accessed keys vary quickly over time.<p>I&#x27;m not sure if memcached handles this well (it requires a lightweight rwlock&#x2F;RCU&#x2F;MVCC mechanism, for instance), but a shared-nothing system like Redis cannot provide good performance in all cases.

I&#x27;m glad antirez spoke up and clarified. I do think Redis is perfectly acceptable as a cache if you make a few config tweaks and run a second instance.<p>Many of the developers I work with are unfamiliar with Redis. Maybe they&#x27;ve heard of it and they install it to use Sidekiq and that&#x27;s it. From the perspective of a newcomer, memcached is &quot;safer&quot; to run because it&#x27;ll be memory limited automatically with literally zero config necessary. Redis does require the non-default LRU and memory tuning to be a safe cache.<p>It sounds like my performance concerns are primarily a thing of the past. Glad to hear it and I look forward to the threaded I&#x2F;O coming after lazyfree.

For a post that attempts to compare Redis to memcached for caching, it&#x27;s amazing how few actual numbers appear in the post.

Some minor points<p>&gt; Redis in its special case of memcached replacement, may be addressed executing multiple processes<p>This is always less optimal to a single process. Simpler is better.<p>&gt; Redis is very very observable<p>This has a cost...trashing your phenomenal read and write performance. Running a concurrent redis, just for monitoring, is a hack that I have used to continue leveraging the observability.

I would guess that Mike Perham&#x27;s point of view is based on how Sidekiq uses Redis for persisting jobs. If you don&#x27;t configure Redis properly and you use Redis as a job queue as well as a cache then you risk the problem of your job queue entries getting evicted depending on your Redis config&#x2F;version of Redis you are using. That type of thing happening frequently would be very annoying for someone that made a job queue that uses Redis for persistence of jobs.<p>Caching web content can grow and grow until you run out of memory. If you aren&#x27;t using Redis for data that can be easily regenerated, then go ahead and use Redis as a cache. But if you are, I think it will give you operational peace of mind to segregate where you store your background jobs and where you cache content.

I cache with redis:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;seamusabshere&#x2F;lock_and_cache" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;seamusabshere&#x2F;lock_and_cache</a><p>(and lock too, with Redis Redlock)

Last time I looked Redis would balk if it ran out of memory whilst memcached just pushed out the oldest caches.<p>I guess that&#x27;s not a problem anymore..?

Both are relatively small projects and really there is no much stuff to compare.<p>I&#x27;m slowly working on my own memcached clone and plan to add persistence there eventually. Not so sure about replication, it might be too hard. In principle, after I&#x27;m done with getting a better version of memcached, both feature-wise and performance-wise, if time permits, I can also add the redis protocol support.<p>Therefore, it will be possible to have both in a single package and don&#x27;t worry finding which one is better.<p>This is my project, if anyone is interested: <a href="https:&#x2F;&#x2F;github.com&#x2F;ademakov&#x2F;MainMemory" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ademakov&#x2F;MainMemory</a><p>[Update: my statement was only about cache-related functionality, admittedly redis supports very interesting data structures, persistence, replication. But as just a very fast in-memory cache, there is nothing particularly advanced in either case. On the other hand there are projects like RAMCloud, Seastar that I find inspiring when I work on my own project.]