While memcache and redis are often compared, I don't think its entirely fair to compare them. Redis and Memcache have very different design goals. I don't think anyone is using memcache as a primary source of truth or wishes it has persistence. Memcache is a cache, Redis is a database.
Redis offers much more than Memcache, even it its at the cost of performance. The article assumes that everyone runs redis like they run memcached. They don't (http://blog.pivotal.io/pivotal/case-studies-2/case-study-how...) and if Salvatore were to fork memcached to try and get many of those features into memcached its doubtful the community would ever accept it. If providing those features came at the cost of performance, it would have been terrible for companies that actually depended on memcache being a fast in memory cache.
It isn't so much that "Redis is better" it is, Redis is more likely aligned with what you are trying to do and more flexible. However I doubt you could convince Facebook to replace memcache with Facebook, for any of the "engineering efforts" that were put into Redis. Likewise, I doubt Facebook would be running a fork of memcache that offered Redis-like features.
Naming the post "Comparison to Redis" and adding some paragraphs about this is a bit glory hunting, because having two buzzwords in the title is better than one :)
Basically it's just Memcached internals discussion and improvements suggestion.
"I feel that if Salvatore Sanfilippo was started Redis by forking Memcached, community would have better in-memory caching solution today."
Article lost me here. is he saying that if the author of redis worked on memcache instead then mencache would be better? Ok.
Or is he saying redis would be better off if it had started as a fork of memcache? Bullshit. My understanding of redis is part of the reason for it was the author wanted to implement a data store from scratch, forking a mature project would have not motivated someone with that goal. Plus as a project matures it becomes harder and harder to make bigger changes. Even a small change requires tons of time. So redis would not have developed so quickly if not for starting from scratch.
Now they think about adding concurrency anyway (https://news.ycombinator.com/item?id=9026344) And one day they will implement that, because it is quite difficult to keep talking that single-threaded database solution is OK in today's server CPU landscape, better non-blocking system IO, etc. Why you think A + B (features + concurrency) is better than B + A (concurrency + features)?
I've always admired memcached use of a hash on the client to know where to store/retrieve data. Unfortunately, it makes it difficult to build ha, but it is a very elegant way to allow scaling horizontally without the need for a catalog server.
Not all, and I believe memcached was one of the first if not the first. IBM eXtreme Scale uses catalog servers, it's definitely not the default on redis (you need specific client libraries), Elastic Search keeps track of where the data is and each node act as a proxy server.
PS: Yes I know, eXtreme Scale and ES do HA, which is not easy to do with client side consistent hashing partitioning.
Redis offers much more than Memcache, even it its at the cost of performance. The article assumes that everyone runs redis like they run memcached. They don't (http://blog.pivotal.io/pivotal/case-studies-2/case-study-how...) and if Salvatore were to fork memcached to try and get many of those features into memcached its doubtful the community would ever accept it. If providing those features came at the cost of performance, it would have been terrible for companies that actually depended on memcache being a fast in memory cache.
It isn't so much that "Redis is better" it is, Redis is more likely aligned with what you are trying to do and more flexible. However I doubt you could convince Facebook to replace memcache with Facebook, for any of the "engineering efforts" that were put into Redis. Likewise, I doubt Facebook would be running a fork of memcache that offered Redis-like features.