Hacker News Reader

Comment by russss | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com