4 ms·

This is not a rhetorical question, I'm asking our of curiosity/ignorance. If you were about to start a new project, for what reasons would you choose Memcached

This is not a rhetorical question, I'm asking our of curiosity/ignorance. If you were about to start a new project, for what reasons would you choose Memcached over Redis? Or probably better said, for which use cases?

rawoke083600 7y ago
I grew up with memcached and it certainly has way less features than redis, but nothing is simpler. For linux+php anyway. From setup to usage.
teej 7y ago
Redis. Back in the day when I ran memcached with the rest of the cool kids, I always wanted something like SADD and LPUSH. Redis is a realization of that vision and using it is always a delight to me.
mrweasel 7y ago
I don't really see those two projects as solving the same problems. Memcache is for caching only, it's very good at it, there is basically no administrative overhead and people (i.e. other developers) know that if you stuff data into memcache, you should be prepared to lose it. Redis is, to me at least, much more akin to "shared data structures as a service". Sure it's also a key value store, where I could cache data, but I could do that with MySQL as well. I look to Redis when I need to have data shared between components, and sometimes a key value store happens to be the best solution, other times it may be pub/sub.
- pachico 7y ago
  Thanks for your answer. I can hardly see Redis as a hard to admin software - vanilla installation should work in most (if not all) scenarios, honestly. This is why I'm asking because, giving that Redis has a great number of extra features and superb performance, it would be hard to justify, at least for me, to choose Memcached. Worst case scenario, you don't use all those extra features. Or am I missing anything?
  - mikeyjk 7y ago
    I'm hoping someone with better knowledge swoops in here, but my understanding is that their are instances where memcached can outperform redis. This article makes some claims: https://medium.com/@Alibaba_Cloud/redis-vs-memcached-in-memory-data-storage-systems-3395279b0941 https://medium.com/@Alibaba_Cloud/redis-vs-memcached-in-memo... A relevant SO post: https://stackoverflow.com/questions/10558465/memcached-vs-redis#11257333 https://stackoverflow.com/questions/10558465/memcached-vs-re... Personally as a dev I would start with redis and only consider swapping if I ran into a perf bottleneck I could prove was better in memcached.
    - pachico 7y ago
      Thanks a lot for sharing this article. It was very helpful. Cheers
  - mrweasel 7y ago
    You're absolutely right that Redis isn't hard to administer, it's just harder than Memcache because it's able to do more, especially once you start thinking about persisting data. I think it really depends if and how you're going to use the Redis features. If you plan to make Redis a big part of your overall design, then maybe separating caching out into Memcache servers still makes sense. One issue I've run into is shutdown and start up time for Redis, when you're storing large amounts of data. You risk being without a caching layer for a large period of time if you need to restart Redis, where Memcache, due to the lack of persistance is ready right away. Honestly I'm not sure it that still an issue, but I believe it is. Of cause this is only an issue if you're using Redis to store other data than just your cache, but the temptation to do so is pretty high once Redis is available to you. You could of cause have two instances of Redis, but if you're not using the features in one of the Redis installation, then maybe you could just as easily use Memcache. As with so much else, it's a question of your use case, how much data you have, what type of data and how you expect to be able to access it.
    - zzzcpan 7y ago
      > You risk being without a caching layer for a large period of time if you need to restart Redis, where Memcache, due to the lack of persistance is ready right away. Honestly I'm not sure it that still an issue, but I believe it is. The bigger issue here is starting an empty (cold) caching instance and overloading backends because all the requests are MISSes and go to the backends. Persistence allows you to avoid this problem. Even if you run caching servers in some geo distributed setup, persistence will still help by reducing unnecessary geo bandwidth. It's pretty hard to find even a single use case where in-memory caching server without persistence is better than the one with.
philliphaydon 7y ago
I would go Redis because I feel Memcached clients in .NET have more or less been abandoned. The main one used for .net core causes problems and I cannot narrow down why :(
- mhd 7y ago
  I think the default Javascript one still can't connect properly to memcache run over a domain socket. So yeah, there's a lot of rust in the client-space.
steve_adams_86 7y ago
There are definitely reasons to consider. At the highest level, I'd say Redis is a swiss army knife and Memcached is a simple pocket knife. Sometimes you really want the swiss army knife, sometimes all of that stuff is just in the way. Memcached is super simple and basic, and that's what I want to lean towards in the building blocks of my software. Looking closer, Redis isn't multithreaded while Memcached is. This means Memcached can scale vertically by scaling compute power in a single instance. Redis isn't well-suited to that. If you're just using a key-value store with zero frills and you run a monolithic app on a single instance, Memcached is going to take you a lot further. A ton of people still run their web applications this way. Having said that, Redis scales horizontally very easily and nicely. You can create replicas of a primary Redis instance to create super high performance/availability clusters. I'd say the lack of multithreading is a non-issue if you know how to manage Redis this way and your infrastructure allows for it. Beyond that, if you do need the features Redis offers (scripting, geospatial support, pub/sub, etc) then Memcached is pretty much off the table. I'm sure there are things I'm missing, but these are the key items that come to mind. They're definitely different! I wouldn't say Redis is the de-facto solution, although I love it and use it a lot.

rawoke083600 7y ago

I grew up with memcached and it certainly has way less features than redis, but nothing is simpler. For linux+php anyway. From setup to usage.

teej 7y ago

Redis. Back in the day when I ran memcached with the rest of the cool kids, I always wanted something like SADD and LPUSH. Redis is a realization of that vision and using it is always a delight to me.

mrweasel 7y ago

I don't really see those two projects as solving the same problems. Memcache is for caching only, it's very good at it, there is basically no administrative overhead and people (i.e. other developers) know that if you stuff data into memcache, you should be prepared to lose it. Redis is, to me at least, much more akin to "shared data structures as a service". Sure it's also a key value store, where I could cache data, but I could do that with MySQL as well. I look to Redis when I need to have data shared between components, and sometimes a key value store happens to be the best solution, other times it may be pub/sub.

pachico 7y ago
Thanks for your answer. I can hardly see Redis as a hard to admin software - vanilla installation should work in most (if not all) scenarios, honestly. This is why I'm asking because, giving that Redis has a great number of extra features and superb performance, it would be hard to justify, at least for me, to choose Memcached. Worst case scenario, you don't use all those extra features. Or am I missing anything?
- mikeyjk 7y ago
  I'm hoping someone with better knowledge swoops in here, but my understanding is that their are instances where memcached can outperform redis. This article makes some claims: https://medium.com/@Alibaba_Cloud/redis-vs-memcached-in-memory-data-storage-systems-3395279b0941 https://medium.com/@Alibaba_Cloud/redis-vs-memcached-in-memo... A relevant SO post: https://stackoverflow.com/questions/10558465/memcached-vs-redis#11257333 https://stackoverflow.com/questions/10558465/memcached-vs-re... Personally as a dev I would start with redis and only consider swapping if I ran into a perf bottleneck I could prove was better in memcached.
  - pachico 7y ago
    Thanks a lot for sharing this article. It was very helpful. Cheers
- mrweasel 7y ago
  You're absolutely right that Redis isn't hard to administer, it's just harder than Memcache because it's able to do more, especially once you start thinking about persisting data. I think it really depends if and how you're going to use the Redis features. If you plan to make Redis a big part of your overall design, then maybe separating caching out into Memcache servers still makes sense. One issue I've run into is shutdown and start up time for Redis, when you're storing large amounts of data. You risk being without a caching layer for a large period of time if you need to restart Redis, where Memcache, due to the lack of persistance is ready right away. Honestly I'm not sure it that still an issue, but I believe it is. Of cause this is only an issue if you're using Redis to store other data than just your cache, but the temptation to do so is pretty high once Redis is available to you. You could of cause have two instances of Redis, but if you're not using the features in one of the Redis installation, then maybe you could just as easily use Memcache. As with so much else, it's a question of your use case, how much data you have, what type of data and how you expect to be able to access it.
  - zzzcpan 7y ago
    > You risk being without a caching layer for a large period of time if you need to restart Redis, where Memcache, due to the lack of persistance is ready right away. Honestly I'm not sure it that still an issue, but I believe it is. The bigger issue here is starting an empty (cold) caching instance and overloading backends because all the requests are MISSes and go to the backends. Persistence allows you to avoid this problem. Even if you run caching servers in some geo distributed setup, persistence will still help by reducing unnecessary geo bandwidth. It's pretty hard to find even a single use case where in-memory caching server without persistence is better than the one with.

philliphaydon 7y ago

I would go Redis because I feel Memcached clients in .NET have more or less been abandoned. The main one used for .net core causes problems and I cannot narrow down why :(

mhd 7y ago
I think the default Javascript one still can't connect properly to memcache run over a domain socket. So yeah, there's a lot of rust in the client-space.

steve_adams_86 7y ago

There are definitely reasons to consider. At the highest level, I'd say Redis is a swiss army knife and Memcached is a simple pocket knife. Sometimes you really want the swiss army knife, sometimes all of that stuff is just in the way. Memcached is super simple and basic, and that's what I want to lean towards in the building blocks of my software. Looking closer, Redis isn't multithreaded while Memcached is. This means Memcached can scale vertically by scaling compute power in a single instance. Redis isn't well-suited to that. If you're just using a key-value store with zero frills and you run a monolithic app on a single instance, Memcached is going to take you a lot further. A ton of people still run their web applications this way. Having said that, Redis scales horizontally very easily and nicely. You can create replicas of a primary Redis instance to create super high performance/availability clusters. I'd say the lack of multithreading is a non-issue if you know how to manage Redis this way and your infrastructure allows for it. Beyond that, if you do need the features Redis offers (scripting, geospatial support, pub/sub, etc) then Memcached is pretty much off the table. I'm sure there are things I'm missing, but these are the key items that come to mind. They're definitely different! I wouldn't say Redis is the de-facto solution, although I love it and use it a lot.