Is Memcached a Good or Bad Sign for MySQL? | Hacker News Reader

Is Memcached a Good or Bad Sign for MySQL?

gigaom.com

11 pointsvladocar13 comments

He's getting it wrong (unsurprisingly).

If you just use Memcache to cache the same results you get out of a DB, of course you might as well just throw that RAM at the DB. With any sane DBMS this will result in the same performance improvement.

The problem with that is that it limits you to the amount of RAM you can throw into the DB. The biggest Memcache clusters reach well into the multi-terabyte range.

Secondly, you can use Memcache to store constructed objects which could take many DB calls (or CPU time) to generate. Now you're getting one Memcache hit instead of several DB hits, which is a distinct bonus.

Since it's shared-nothing, Memcache also gives you the ability to massively parallelize queries to many cache servers at once, and get a much quicker overall response than just hammering one DB into the ground.

I've never used memcache, but my understanding is that memcache stores the results of queries whereas adding ram to the database will perhaps help it store indexes, tables, and query compiles, but to the best of my knowledge, the results of queries are not stored by DBMSs -- this is why memcache is used.

If my understanding of memcache is correct, throwing more ram at the db won't provide the same performance improvements that memcache will provide.

MySQL has a query cache which stores results of queries, though it's not very useful if you have frequent writes.

Linux and other operating systems tend to use any free memory for disk cache which will end up caching the whole database if needed.

Innodb has a key cache.

Memcached probably helpful on the database server but it's really designed to be ran somewhere else so that database server has as much memory as possible of it's own.

mysql has a query cache, which stores the query and results:

http://dev.mysql.com/doc/refman/5.1/en/query-cache.html

With the query cache, if you update a single row in one table, all cached queries that involve that table are invalidated, whether or not that row would have affected the result. This makes it almost useless for many sites.

you might as well just throw that RAM at the DB. With any sane DBMS this will result in the same performance improvement.

That is obviously false.

A memcache hit is much cheaper than a DBMS query, even if the DBMS query is accessing data that resides in the DB's buffer cache. If the DB query we're comparing against memcache is a trivial one (a single b-tree lookup), a memcache lookup is still faster; if the DB query is at all non-trivial, the memcache performance advantage is larger.

In my experience, any differences between simple key/value lookups from Memcache and those from cache in a decent DB are easily lost in the network round-trip noise (i.e. solidly sub-millisecond).

(of course more complex queries will be slower, but I covered that in my second point)

Memcached with UDP get can handle 400k gets per second (from a facebook engineering note earlier this year) on a single commodity server. Which "decent" DB can even approach this even for simple queries? A cache server and DB server simply have different performance priorities. Memcached makes a lot of sense for caching application specific fragments that has application specific expiration policies.

Regarding your 2nd point, latency != 1/throughput when you have parallel queries.

From my point of view, memcached isn't a godsend because the database is weak, it is a godsend because it prevents you from trying to do things that no database should be asked to do.

My personal projects use memcached recently, but not for anything interesting. At the day job, we have a particular case where we render a per-user sidebar. The data for the sidebar is volatile, but unpredictably volatile -- i.e. it should be unchanging for the length of a user session except when it isn't, but when it isn't the user requires us to know Right The Heck Now (TM). That data is actually stored on another system, and accessing it requires hitting a web service on the other system. Accessing the web service is, obviously, an overhead, and the service it calls is very heavy. Obviously, big win for us if we can avoid hitting that service on every request for a webpage with a sidebar.

Enter memcached. It is a fairly simple way to keep the sidebars for 3+ app servers synced with each other, and the other system can force-expire the cache if it wants to. This isn't a knock against the database running on the other system -- it doesn't and shouldn't care about what format we use their data in, just that they're keeping the contract about providing it when we ask and pinging us when it needs expiry.

How are you having the other system expire the cache?

As I've been involved in a similar project, for my part I set up a very simple web service that handled the invalidation. The third-party service only needed to know the user session key or the user database ID, and then send a HTTP DELETE to the relevant API method, and the main app server did the rest.

The increase in development for memcached is a good thing since it's a relatively easy and less expensive way to scale. As mentioned in the article, relational databases will be around for a while and were never designed for the kind of scale that many companies require today. It's a proven technology that just needs a boost in certain situations.

The combination of MySQL + Memcached is a great solution to for many small companies to scale.

> As mentioned in the article, relational databases will be around for a while and were never designed for the kind of scale that many companies require today.

MySQL is not representative of all relational databases.

Reply on news.ycombinator.com