MySQL cluster vs memcached
lists at benrey.is-a-geek.net
Sun Oct 15 06:10:57 UTC 2006
Kevin Burton wrote:
> Ultimately your performance is governed by the speed of your
> disks, how
> or better is easily possible for my mysql replication cluster. So my
> limit is roughly converging to "how many writes I can push" into a
> I'd prefer to NOT have disk involved......... I'm curious if you could
> in theory use NDB as a replacement for memcached... there would be no
> LRU semantics of course.
> With 5.1 and disk support you can at least have larger DBs and just
> add more machines to your cluster if you need more throughput.
Well, without knowing your application's requirements, I might be
missing your point. I see memcache and mysql as two layers in a three
layer cake. I would not consider NDB a replacement for memcached at all.
NDB will be performing queries and memcache is just a cache, it's not
executing the cycles doing joins, sorts and orders. Compared nearly any
non-cached query that takes one second, the time cost of using memcache
is effectively zero. If your application has queries using temporary
tables and temp files in mysql, you probably want to be caching your
results for at least the time it takes to do just one of those queries.
Also, your mysql-cache results are regularly destroyed upon changes to
the tables they involve, and I presume that NDB would behave the same
way. (If your application requirements do not tolerate cache-latency,
As for avoiding disk...that's a requirement I'm not facing. NDB might be
a solution for you. You won't know until you bench it out.
I'd get the book "MySQL Clustering" and research the capabilities of NDB
before throwing your weight on it.
I'd also read this ONLamp article about 5.1 clustering:
NDB is not a technology that is a scaled up 5.1. You're going to have
your disk subsystem for persistence of course (those are the NDB storage
nodes.) Your worker nodes likely need more ram than a caching solution,
because they are not only holding the indicies you're querying against,
they need to have the space to hold the join and sort buffers to process
queries. NDB has limitations on row size, no referential integrity, and
join performance is worse in NDB than in normal MySQL. (IIRC, large
joins are poor performers because data is spread across the cluster's
memory, so you could involve network latency during the join.) The
number of joins I'm doing on my schema might necessitate me to use
memcache on NDB even if I were using NDB.
The rate at which you would scale your memcache resources and your NDB
resources are going to be totally different.
With memcache, I just need to upgrade a bunch of my servers to using
8x2048MB DIMMs. With NDB, I need to buy a whole new (at least 4)
machines, possibly another cabinet, PDU, serial management and second
power circuit just for them. My existing cabinet already needs a mesh
door with fans because those Dell PE servers may as well be SUVs the
heat they generate.
In my case, memcache should allow me to avoid needing NDB entirely. If I
considered NDB, I would likely have to audit my application and possibly
re-schema it to fit the requirements of NDB. My application doesn't need
that yet. I hope I don't get tasked with those requirements any time soon.
I'm grateful for memcache and I plan to get a lot out of it.
More information about the memcached