Memcached 1.6 | Hacker News Reader

Memcached 1.6

github.com

110 pointsnrr46 comments

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?

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.

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.

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.

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?

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-memo...

A relevant SO post: 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.

Thanks a lot for sharing this article. It was very helpful. Cheers

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.

> 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.

I agree with you 100%. I've personally suffered from caching stampedes (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.

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

I wasn't aware of this project. Is it as good as advertised?

Worked well in my testing so far, mainly to have the Redis API with a far larger dataset than RAM.

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.

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.

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.

Boring Tech is Good. Memcached should be added to that list.

Edit: Release Note Mentioned Netflix, I wonder what they use it for.

> Boring Tech is Good

It's fine if all you are doing is boring things.

But often there are use cases where a simple key/value store just isn't going to cut it.

And I for one am glad to have Redis as a solid, well-engineered alternative.

You can do boring things with cool tech and cool things with boring tech. I'm not sure if they even correlate.

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-ca...

What I like about Memcached is it's just that, it works, written in C, oh and my goodness uses Perl tests!

It's not re-written every other year in the latest hot language. It chugs along, without embarrassment, doing one thing amazingly well over 17 years...

It used to be written in Perl, back in the day... I suspect some of those tests are quite likely to be from back then.

I smiled when I read the title, thinking "How cool! Something I was using at a job I left ~16 years ago has _finally_ made it to version 1.6!" :-)

(I suspect the old LiveJournal Perl code probably didn't have it's version numbers carry over into this somewhat more modern version...)

> It's not re-written every other year in the latest hot language

What is with all of the weird sniping in this thread ?

There are legitimate reasons why people move to Rust and similar languages e.g. security, maintainability.

> "It's not re-written every other year in the latest hot language."

What project does this?

Redis tests are written in tcl! both perl and tcl are awesome!

Snapchat is one of the largest if not the largest user of memcached on GCP, a few years ago they were +100TB and growing like a weed!!

That seems horrible.

Memcached is state of the art for caching and most of the big players on the internet use it. Nice work, dormando.

Been using memcached for >7 years now. Just thank you! It's been adding great benefits to almost all of my projects.

Memcached doesn't pander or resort to marketing to achieve a userbase (compare to redis/labs). It's a great piece of software engineering and I absolutely respect that there's no gimmick, no bullshit. Just a lot of hard work given away for free. Great work!

Thanks!

> Memcached doesn't pander or resort to marketing to achieve a userbase (compare to redis/labs)

I think this is pretty unfair to Redis. Redis has a lot more features (tell me which ones you think are pandering, and to whom?), is free for the vast majority of what people want to use it for, and the attempt to make some money through Redis Labs is pretty recent in the scheme of things. If that helps with the continued development of Redis I have no problem with it.

While I don't want to take anything away from memcached, I'm puzzled by the swipe at Redis. Whatever marketing you're referring to, Redis supports some pretty useful data structures that make some pretty common query patterns trivial (eg top-N queries) and does it with a small, elegant core of some of the most readable code ever produced.

Memcache OTOH is a fairly simple KV cache. It seems to be pretty decent. Neither of these supplants the other however. Hence my puzzlement. It just seems out of place, unnecessary and doesn't really add anything.

I have a trading bot that consolidates a lot of price information in order to make decisions. I'm currently using Redis due to data structures (lists and scores) and Pub/Sub.

I wonder if memcached would give me performance benefits and lower my CPU costs.

CPU is cheap and 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.

You can always just JSON-encode whatever you’re putting in there and decode on the way out. Though I couldn’t imagine using it for pub/sub like the parent commenter is doing with redis.

Which is inefficient and pointless compared to just using Redis with data structures that you can manipulate directly.

Mind giving some examples in more detail about how you make use of lists/scores?

Pub/Sub is easily replaceable. I use lists and scores to store orders from orderbooks, where the prices are the scores. Then I can order by price.

It's simple, but I have like 400 updates per second.

You'll get a bunch of garbage answers here to be frank, from people who never put more than trivial load through both.

Memcache blows redis out of the water in terms of raw throughput and latency, like it's not even remotely close on modern lots of cores and big memory machines.

Redis has a more feature rich api, but has fundamentally hobbled itself on a root hash table and concurrency implementation that is circa 1990.

Give memcached a try, even if it means you implement some stuff you currently defer to redis ops. Measure it. Look at the code bases. Make up your own mind about performance and which actually makes your code simpler.

http://antirez.com/news/94

TL;DR: Redis is just doing different things, and the slab allocator is pretty efficient in regards to performance but not memory usage.

Fwiw this post comparison is pretty old. The memory usage should be the same or better these days (automatic slab rebalancing, LRU expired item crawler, chunked items, etc).

Thanks. I'll make sure to create a PoC and post back here.

This was the first non-sql datastorage I used for online services; a lifetime ago. Glad to see that it is still maintained.

I wouldn't be surprised if there is more data cached by memcached than redis with all the massive players using. Hardly a dead project.

I still use Memcache in a handful of old PHP projects I’ve been keeping on life support since the mid 2000s. I’m also glad it’s being maintained! It’s perfectly fine at what it was designed to do.

Reply on news.ycombinator.com