

Is Memcached a Good or Bad Sign for MySQL? - vladocar
http://gigaom.com/2009/05/17/memcached-and-an-ailing-mysql/

======
russss
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.

~~~
pj
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.

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

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

~~~
chrisbolt
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.

------
patio11
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.

~~~
bobbyi
How are you having the other system expire the cache?

~~~
henriklied
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.

------
neovive
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.

~~~
silentbicycle
> 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.

