From the stories on HN one would think that everyone who used memcached is replacing it with redis. Is that really the case? What are the differences and similarities?
My experience has been that many people are using redis instead of memcached. I haven't switched myself, but it seems some frameworks of various types (ServiceStack, Resque, others) build in a Redis-based caching mechanism, and that's driving most of the adoption for Redis-as-a-cache. Perhaps some of the motivation is that it's easier to kinda-sorta run Redis on Windows than it is to run memcached on Windows.
Memcached has been running on Windows for a fair bit longer than Redis, and it's in mainline Memcached, though not mainline Redis, now. Of course, neither are necessarily that production-tested, but most people wouldn't be looking to use Windows servers anyway.
1 thing I appreciate about memcached is that it is always fast. Redis has a wider variety of features and capabilities, which can come back to bite you if/when the whole app is slow due to some poorly thought out Redis query -- especially likely if you're using Redis to do multiple things, such as (1) store temp cache data and also (2) store user account data.
What do you mean by query? Are talking about using the 'keys' command to figure out what data you need? Because that's completely discouraged for everything except maintenance tasks, and for those I think it makes sense to keep an extra slave instance that is not used by any apps that connect to redis (i.e., keep it out of the pool they can use).
If on the other hand by 'query' you mean, for example, using operations like diff, intersect, and union on sets that store keys (for the purpose of knowing what data to pull) -- I actually haven't ran into performance problems yet. If what you're saying is "it's important to spend time to think about HOW you're going to be determining what data to access", then yeah, I'll completely agree that this is crucial. However, I will also point out that this will be true even if you're using a relational database -- though those are expected to be "queried" so perhaps designing a feasible solution is a bit less demanding.
I ditched memcached for redis a while ago, just because I was already using redis for my queueing, and it made sense to eliminate redundant dependencies.
I'm now using Redis clusters to distribute cache reads so that each webserver has its own local copy of the cache which it reads from, but there's a single master that accepts writes. This does occassionally mean a double-write, but since we're talking about cache data and redis is atomic, this isn't a problem, and it splits the load of my reads, so that I don't end up bottlenecking if the master is being slow.
I'm not an expert with either redis or Memcached, but in my personal usage, Memcached is functionally at least equal to redis for the things that it does well like LRU caching.
I find myself continuing to use it for those things just to keep my redis config cleaner and optimized for the things redis is (seemingly) better for like persistent storage and message queues.
Redis can be run without persistence, at which point it can be treated as Memcached with extra features (optimistic locking, data structures, etc). Without persistence, performance is often comparable (even with persistence, performance can be comparable, but you're more at the mercy of the IO subsystem).
Comments
From the stories on HN one would think that everyone who used memcached is replacing it with redis. Is that really the case? What are the differences and similarities?
Here's a pretty good comparison of the two - http://stackoverflow.com/questions/10558465/memcache-vs-redi....
Disclaimer: I wrote the above article and work for RedisToGo. But that article is unbiased :)
My experience has been that many people are using redis instead of memcached. I haven't switched myself, but it seems some frameworks of various types (ServiceStack, Resque, others) build in a Redis-based caching mechanism, and that's driving most of the adoption for Redis-as-a-cache. Perhaps some of the motivation is that it's easier to kinda-sorta run Redis on Windows than it is to run memcached on Windows.
I suspect that most of it is that you can kill two birds with one stone by using redis as your task queue. That's what I do.
Memcached has been running on Windows for a fair bit longer than Redis, and it's in mainline Memcached, though not mainline Redis, now. Of course, neither are necessarily that production-tested, but most people wouldn't be looking to use Windows servers anyway.
1 thing I appreciate about memcached is that it is always fast. Redis has a wider variety of features and capabilities, which can come back to bite you if/when the whole app is slow due to some poorly thought out Redis query -- especially likely if you're using Redis to do multiple things, such as (1) store temp cache data and also (2) store user account data.
What do you mean by query? Are talking about using the 'keys' command to figure out what data you need? Because that's completely discouraged for everything except maintenance tasks, and for those I think it makes sense to keep an extra slave instance that is not used by any apps that connect to redis (i.e., keep it out of the pool they can use).
If on the other hand by 'query' you mean, for example, using operations like diff, intersect, and union on sets that store keys (for the purpose of knowing what data to pull) -- I actually haven't ran into performance problems yet. If what you're saying is "it's important to spend time to think about HOW you're going to be determining what data to access", then yeah, I'll completely agree that this is crucial. However, I will also point out that this will be true even if you're using a relational database -- though those are expected to be "queried" so perhaps designing a feasible solution is a bit less demanding.
I ditched memcached for redis a while ago, just because I was already using redis for my queueing, and it made sense to eliminate redundant dependencies.
I'm now using Redis clusters to distribute cache reads so that each webserver has its own local copy of the cache which it reads from, but there's a single master that accepts writes. This does occassionally mean a double-write, but since we're talking about cache data and redis is atomic, this isn't a problem, and it splits the load of my reads, so that I don't end up bottlenecking if the master is being slow.
Memcached has some rough edges (e.g. slab size management) that aren't there in Redis. Redis also gives you a couple extra useful primitives.
I'm not an expert with either redis or Memcached, but in my personal usage, Memcached is functionally at least equal to redis for the things that it does well like LRU caching.
I find myself continuing to use it for those things just to keep my redis config cleaner and optimized for the things redis is (seemingly) better for like persistent storage and message queues.
Redis can be run without persistence, at which point it can be treated as Memcached with extra features (optimistic locking, data structures, etc). Without persistence, performance is often comparable (even with persistence, performance can be comparable, but you're more at the mercy of the IO subsystem).