Re: Grid skepticism

  • From: Nuno Souto <dbvision@xxxxxxxxxxxxxxx>
  • To: oracle-l@xxxxxxxxxxxxx
  • Date: Thu, 24 Jun 2004 22:36:53 +1000

Mark Leith apparently said,on my timestamp of 24/06/2004 9:30 PM:

> Actually, I think Nuno was referring to its clustering/scalability. 

Precisely.


> But, I concur that he may have been wrong anyway:
> 
> http://www.mysql.com/products/cluster/faq.html
> 

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.

-- 
Cheers
Nuno Souto
in sunny Sydney, Australia
dbvision@xxxxxxxxxxxxxxx
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Other related posts: