Memcached and Redis
- source: https://news.ycombinator.com/item?id=22522005 March 9, 2020
Do you still remember Memcached? To me, It reminds me of Perl. It was developed by Brad Fitzpatrick when he was working at LiveJournal. He is probably mostly known for his recent creation of Go language.
Memcached does one thing. Redis does a bunch. They are different.
Note that Redis had Virtual Memory but deprecated in favor of Redis on Flash. read here and Redis 2.4 is the last Redis version featuring Virtual Memory.
In a nutshell, VM stores rarely used large value to disk and load it back to memory when required again. This allows one to use less memory than required.
Memcached supports it via Extstore.
We hardly hear Memcached anymore and let’s see what people will say about it and redis:
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.
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
A relevant SO post: https://stackoverflow.com/questions/10558465/memcached-vs-redis#11257333
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.
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
Client side support issue? See if your language support Memcached well.
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 :(
- 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.
It is interesting to see how Memcached and Redis, what was once competing in the same space, diverge in development. Redis continue to add features on top of features, it isn’t bloat by any means, but it is still a lot more than say Redis 2.x. While Memcached stayed pretty much the same as memcahched 1.4, which was released over a decade ago. Optimising every single bit out of it and allow cache to be extended to SSD.
- Regarding Netflix, here’s a big usage of theirs, which is the Extstore (external flash storage) the Github page refers to. They probably use it beyond this, but it’s a good technical article to sink your teeth into. https://netflixtechblog.com/evolution-of-application-data-caching-from-ram-to-ssd-a33d6fa7a690
if you do need the features Redis offers (scripting, geospatial support, pub/sub, etc) then Memcached is pretty much off the table.
memcached has no advanced data structures. If you’re using them then you’ll probably have to reimplement everything yourself in memcached with less efficiency.
This medium blog post echoes comment above about the data structure feature supported by redis.
Redis supports server-end data operations, and owns more data structures and supports richer data operations than Memcached. In Memcached, you usually need to copy the data to the client end for similar changes and then set the data back. The result is that this greatly increases network IO counts and data sizes. In Redis, these complicated operations are as efficient as the general GET/SET operations. Therefore, if you need the cache to support more complicated structures and operations, Redis is a good choice.