Mario Beck:

But the memcached plugin to MySQL is a replacement or addition to the SQL interface to MySQL. So instead of using SQL queries in your application to persist or retrieve data from MySQL you can use the memcached interface. And what are the benefits?

• Much higher performance (nb: reduced latency, higher throughput) Easier scalability via sharding Simpler application coding

Plus Baron Schwartz’s cogent addition:

I think a huge benefit you’re discussing, but not naming separately, is consistently. With memcached, you have two copies of the data, and the man with two watches never knows what time it is. With a memcached interface to MySQL, you have only one copy — and it is consistent. This is a huge win.

Original title and link: The Benefits of the MySQL Memcached Plugin (NoSQL database©myNoSQL)

via: http://mablomy.blogspot.com/2012/03/why-should-i-consider-memcached-plugin.html

Interesting comments on StackOverflow:

So, honestly - Is memcache really that old dinousaur that is a bad choice from a performance perspective when compared to this newcomer called Redis?

Here’s mine: feature-wise Redis has already overpasssed Memcached in almost all aspects. Redis 3.0 will bring Redis Cluster a distributed implementation of a subset of Redis standalone—check this for an detailed explanation of Redis Cluster. Production-wise though, Memcached will not be replaced so easy as so many services rely on it for quite some time.

Original title and link: Is Memcached a Dinosaur in Comparison to Redis? (NoSQL database©myNoSQL)

via: http://stackoverflow.com/questions/2873249/is-memcached-a-dinosaur-in-comparison-to-redis

The traffic of our football news syndicating website (Kick News) has been steadily growing a lot since it launched. When we redeveloped it a couple of years ago, we used an in-process cache, by creating an IQueryable extension method that uses an md5 hash of the underlying SQL query as the key. This worked reasonably well, but has it’s obvious problems, such as the caches needing to be refilled when the app pool recycles or when the server is restarted. On our busy site, this means we had to wait until the caches are full before we serve any requests or it would overload our database server, which is unacceptable. Before the site gets any busier we’re going to move to an out-of-process cache and the are 3 main options we’ve considered are Redis, Memcached and Windows Server AppFabric 

From these 3 solutions, only Redis will help address the cache warm-up issue.

Original title and link: Cache Warm-Up: Redis vs Memcached vs Microsoft AppFabric (NoSQL database©myNoSQL)

via: http://www.ichi.co.uk/post/18280190946/microsoft-appfabric-vs-redis-windows-port

While the authoritative storage is Amazon RDS, 99designs is using Redis, MongoDB, and Memcached for transient data:

We log errors and statistics to capped collections in MongoDB, providing us with more insight into our system’s performance. Redis captures per-user information about which features are enabled at any given time; it supports our development stragegy around dark launches, soft launches and incremental feature rollouts.

It’s also worth noting the nice things they say about using Amazon RDS:

An RDS instance configured to use multiple availability zones provides master-master replication, providing crucial redundancy for our DB layer. This feature has already saved our bacon multiple times: the fail over has been smooth enough that by the time we realised anything was wrong, another master was correctly serving requests. Its rolling backups provide a means of disaster recovery. We load-balance reads across multiple slaves as a means of maintaining performance as the load on our database increases.

Original title and link: 99designs: Powered by Amazon RDS, Redis, MongoDB, and Memcached (NoSQL database©myNoSQL)

via: http://99designs.com/tech-blog/blog/2012/01/30/infrastructure-at-99designs/

After giving its source code a look-over, I noticed that the important component is missing - Memcached. Memcached is the de facto standard free & open source, high-performance, distributed memory object caching system, as you know. The other PaaS also supports Memcached (ex. Google App Engine, Heroku, Amazon Web Service, and so on) in various way. I believe that a lot of PaaS users want to use Memcahced, therefore, I decided to implement Memcached as a Service for Cloud Foundry.

The Java world isn’t so big into Memcached. But that’s not a good excuse for not having support for Memcahed in Cloud Foundry.

Original title and link: Memcached as a Service for Cloud Foundry (NoSQL database©myNoSQL)

via: http://tozw.blogspot.com/2012/01/memcached-as-service-for-cloud-foundry.html

While there are some advatanges for using a Membase cluster on EC2 instead of an ephemeral Memcached-based service like Amazon ElastiCache, one question remains: self-managed vs managed? Answering it is essential to undertand the final OPEX.

Advantages of using a Membase cluster instead of ElastiCache:

• persistent vs ephemeral data
• backup & restore
• SASL authentication
• using reserved instances
• cluster elasticity with automatic rebalancing and no need to cache warming

When calculating the OPEX for each of these solutions, one would need to account for:

• licensing fees ^[1]
• monitoring, maintenance, repairs
• salary and wages

In terms of service fees here is a quick comparison:

Original title and link: Membase Cluster on EC2 or Amazon ElastiCache? (NoSQL database©myNoSQL)

via: http://forecastcloudy.net/2011/12/06/membase-cluster-instead-of-elasticache-in-5-minutes/

Von Sebastian explains all 38 of them.

Original title and link: Memcached Stats Explained (NoSQL database©myNoSQL)

via: http://www.pal-blog.de/entwicklung/memcached/2011/memcached-statistics-stats-command.html