
Memcached 1.6 - nrr
https://github.com/memcached/memcached/wiki/ReleaseNotes160
======
pachico
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?

~~~
mrweasel
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
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?

~~~
mrweasel
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
_> 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
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.

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

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

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

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

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

------
subsaharancoder
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!!

~~~
Tostino
That seems horrible.

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

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

------
coleifer
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!

~~~
dormando
Thanks!

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

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

~~~
dijit
[http://antirez.com/news/94](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.

~~~
dormando
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).

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

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

