MySQL cluster vs memcached

[Jed Reynolds]

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
>     table.
>
>
> 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, 
avoid memcache.)

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.
http://www.amazon.com/MySQL-Clustering-Alex-Davies/dp/0672328550

I'd also read this ONLamp article about 5.1 clustering:
http://www.onlamp.com/pub/a/onlamp/2006/04/20/advanced-mysql-replication.html

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.

Jed