News for hackers. Stuff that matters.

A comment on Facebook's Top Open Data Problems. Parent comment

Re:Facebook's Top Open Data Problems by Goranek on Tuesday November 04, 2014 @04:59PM (#8559319)
Simple scales better than complex. What they need is key->value caching and for that memcached is a perfect match. I'm not saying that Redis is bad, but when all you need is key-value memory caching, redis isn't needed.
[ Parent | on HN ]
Re:Facebook's Top Open Data Problems by seiji on Tuesday November 04, 2014 @05:27PM (#8559446)
when all you need is key-value memory caching, redis isn't needed.

Balderdash. memcached is actively hostile to modern infrastructure and it's not being actively developed except for routine maintenance.

The first time someone stores an entire data structure in a memcache key is the moment you've lost. Playing "read blob, deserialize, update, serialize, write blob" is just dumb when you can avoid it.

Other moments of great failure with memcached: needing to implement client-side or proxy-based replication, having the memcached process refuse to cache more things because a slabs become broken, the first time your developers don't understand memcached LRU is per-size category and not global, ....

Just Say No to Memcached.

[ Parent | on HN ]
Re:Facebook's Top Open Data Problems by rbranson on Tuesday November 04, 2014 @05:59PM (#8559587)
You shouldn't be doing read-modify-write cycles in memcached. It's use is as a demand-filled, look-aside cache. Modern open source memcached has slab reallocation that works quite well. It certainly beats a malloc() heap, which will become highly fragmented and inefficient.
[ Parent | on HN ]
Re:Facebook's Top Open Data Problems by otterley on Tuesday November 04, 2014 @06:27PM (#8559688)
> it's not being actively developed except for routine maintenance

Why gild the lily?

> needing to implement client-side or proxy-based replication

It's best practice to replicate the persistent store for availability, not the cache.

Almost all your other concerns appear to arise out of fundamental misuse. It's a cache, not a panacea to cover up basic design flaws in a primary data store.

[ Parent | on HN ]