4 ms·

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

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.
  - pachico 7y ago
    I agree with you 100%. I've personally suffered from caching stampedes (https://en.wikipedia.org/wiki/Cache_stampede https://en.wikipedia.org/wiki/Cache_stampede) and having, at least, a partial cache is a phenomenal feature. (Needless to say, I have learned the hard way not to let evict all cache items at the same time but to have a TTL which is a random number between min and max.) Regardless of this, I still feel bad every time a TTL based cache is used since I strongly favour event based evictions, but this is a totally different (and very long) topic.
manigandham 7y ago
There are also forks/variations of Redis with the same API and various other features. One option is KeyDB which has multithreading and persistence beyond RAM capacity: https://github.com/JohnSully/KeyDB https://github.com/JohnSully/KeyDB
- pachico 7y ago
  I wasn't aware of this project. Is it as good as advertised?
  - manigandham 7y ago
    Worked well in my testing so far, mainly to have the Redis API with a far larger dataset than RAM.

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.
- pachico 7y ago
  I agree with you 100%. I've personally suffered from caching stampedes (https://en.wikipedia.org/wiki/Cache_stampede https://en.wikipedia.org/wiki/Cache_stampede) and having, at least, a partial cache is a phenomenal feature. (Needless to say, I have learned the hard way not to let evict all cache items at the same time but to have a TTL which is a random number between min and max.) Regardless of this, I still feel bad every time a TTL based cache is used since I strongly favour event based evictions, but this is a totally different (and very long) topic.

manigandham 7y ago

There are also forks/variations of Redis with the same API and various other features. One option is KeyDB which has multithreading and persistence beyond RAM capacity: https://github.com/JohnSully/KeyDB https://github.com/JohnSully/KeyDB

pachico 7y ago
I wasn't aware of this project. Is it as good as advertised?
- manigandham 7y ago
  Worked well in my testing so far, mainly to have the Redis API with a far larger dataset than RAM.