RE: Grid skepticism

Yes, I agree with everything you say. MySQL's clustering is nothing like
RAC, or grid. I was simply replying to the "MySQL simply has NO SUPPORT
for "throw as many servers at the problem as they need". It ain't work
that way..." comment - as it looks like you will be able to do this -
from the next release anyway, and most probably not "as many servers at
the problem as they need".

I readily admit that MySQL has quite a way to go before they compete
with anything like Oracle ;)

this is where I ask that you folks *read* the article in detail. Let's
stay within the realms of sensible technical talk, please! Rather than
wishful thinking, or marketing "tick-boxes".

Clustering and grid are not interchangeable terms. Or else
VMS was a grid. Somehow I don't think so...

The clustering of mySQL is in fact along the same lines of
the disk clustering in VMS: a node runs the SQL engine, other nodes
execute the parsed SQL. Remember the cluster controller and intelligent
controllers of VMS? Same old, same old. That is also called two-tier
client server architecture, but I'll pass on details. I'm sure everyone
can read the article for themselves and those with past VMS experience
will click into it straight away.

The first claim of mySQL cluster is failover capability.
That means the load of ONE individual server can be picked
up by ANOTHER individual server. It does NOT mean that the load of one
server can be SPREAD across a number of others. Nothing new here. Been
there, done that with other databases. Don't even need RAC for that,
just an horizontally partitioned application.

The two things are as remotely similar as day and night!
I don't think I need to go into details of locking, optimisation,
application partitioning et all to explain this, do I? Been done
ad-nauseum.

The next claim made is that performance is fast. No qualification
whatsoever. I can partition the load of an application horizontally
across a number of nodes (*IF* I can afford the expense to design it
this way so I can avoid cross-node problems), then I can run portions of
that application in EACH of those nodes and call it all one single
application with amazing performance. Nothing new here. Shades of the
SQL Server "distributed benchmarks" of a few years ago, anyone?

This is a TOTALLY different proposition from the grid, where you do NOT
partition an application horizontally by design, you simply add more
nodes and it runs across those, ALL of it: no change whatsoever needed,
no fancy design needed. Hopefully according to "uncaLarry", all is rosy
and smells of a baby's freshly washed skin. We all know it isn't, but
the principle of operation is the issue here. It really works that way.
NOT the cluster way.

The last claim is scalability. That is *specifically* indicated as: for
cost-effective scale-out, add: more storage nodes, more CPUs (to each
computing node) or more memory per storage node. That, I'm afraid is a
totally different proposition from the
grid: just add a complete node (whatever its capacity)
and be done with it.

They are not dumb, are they? The above "scalability" has
only been available for the last 40 years, but it's all new now? :)

Let's face it once and for all: shared-nothing architectures REQUIRE
special application design in order to scale in a discrete node
implementation. Period, no arguments. Let's not even WASTE time
discussing it!

I am not saying it is bad or good. Just the nature of the beast. For my
money and given the nature and non-design and non-integration of most
modern web-based applications, the shared-nothing model has a lot to
offer: it's simple and it can be implemented on the cheap.

But it is not by any means comparable to the grid in being able to pick
ANY type of application and make it scalable across discrete nodes.

Is that desirable or not? I don't know. Personally I think the two
concepts are needed, because not all needs are the same.