RE: Grid skepticism

Hi Nuno,

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 ;)

Cheers,

Mark

-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Nuno Souto Sent: 24 June 2004 13:37
To: oracle-l_at_freelists.org
Subject: Re: Grid skepticism

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_at_optusnet.com.au
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request_at_freelists.org put
'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.707 / Virus Database: 463 - Release Date: 15/06/2004
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.707 / Virus Database: 463 - Release Date: 15/06/2004
 

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request_at_freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------