what's "share-nothing archtecture"?

[Hardy]

I'm pretty new in this field. when reading some 70x material, I met with
this term but cannot catch its accurate meaning. who can help me? thanks in
advance:)~

[Mark A]

"Hardy" <yh********@hot mail.com> wrote in message
news:cc******** ***@mail.cn99.c om...

I'm pretty new in this field. when reading some 70x material, I met with
this term but cannot catch its accurate meaning. who can help me? thanks in advance:)~

Share-nothing architecture refers to parallel processing where a table is
divided into multiple partitions so that the database can work
simultaneously on each partition in parallel. For best results and the most
scalability, each partition would not share hardware resources with other
nodes. These hardware resources include memory, disk drives, disk
controllers, processors, etc. Hence the term, share-nothing.

In a true share-nothing architecture, each database partition is on a
separate computer (physical node) with a high-speed interconnect between
them. This architecture was invented by Teradata, which used multiple Intel
386 PC's and a proprietary operating system in the early 1980's.

Today, with the advent of SMP (Symmetrical Multi-Processing) machines, a
single computer can have multiple CPU's, multiple disks and controllers, and
OS which can effective share memory and other resources among multiple
processes running on a single computer at the same time. However
share-nothing still provides the ability to have linear scalability to very
large databases, whereas the scalability of SMP is not quite linear and
reaches a saturation point at some level.

Most parallel implementations with DB2 are a hybrid of share-nothing and
SMP, where there are multiple physical nodes, but each one is SMP machine.
So in this case, you might have 6 nodes (computers) each with 4 CPU's, and a
total of 24 database partitions (4 per node). True share-nothing would be
one database partition per physical node.

Share-nothing is also used to distinguish DB2 and Teradata from other
parallel implementations such as Oracle, which is not capable of true
share-nothing, even if you had one partition per node, because of the way
the Oracle parallel database works internally. Even though Oracle is not
capable of true share-nothing, it works well for moderate sized parallel
processing of data warehouses, but not quite as good as DB2 and Teradata.
Oracle multiple node implementations , because they are not true
share-nothing, actually enhances its ability to implement failover
capability, expressly because of its lack of a true share-nothing
architecture.

[Data Goob]

Hardy wrote:

I'm pretty new in this field. when reading some 70x material, I met with
this term but cannot catch its accurate meaning. who can help me? thanks in
advance:)~

did you try google? It amazes me how people don't use google.

http://www.google.com

Put in the word "shared-nothing"

http://db.cs.berkeley.edu/papers/hpts85-nothing.pdf

[Daniel Morgan]

Mark A wrote:

Share-nothing is also used to distinguish DB2 and Teradata from other
parallel implementations such as Oracle, which is not capable of true
share-nothing, even if you had one partition per node, because of the way
the Oracle parallel database works internally. Even though Oracle is not
capable of true share-nothing, it works well for moderate sized parallel
processing of data warehouses, but not quite as good as DB2 and Teradata.
Oracle multiple node implementations , because they are not true
share-nothing, actually enhances its ability to implement failover
capability, expressly because of its lack of a true share-nothing
architecture.

I was going to ignore this until I got to this paragraph. Oracle is
not 'incapable of true shared-nothing' ... it is designed with an
entirely different architecture and has no interest in trying shared
nothing.

Well actually Oracle was shared-nothing through version 5 or 6 but
rejected it because of the very issues we have beaten to death multiple
times so I'll no belabor the point again.

Suffice it to say that Oracle, like DB2 on mainframes, is a
shared-everything architecture by intent and no-one I am aware of with
experience with shared-everything has indicated any desire to return
to the bad old days.

--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.wash ington.edu
(replace 'x' with a 'u' to reply)

[Mark A]

"Daniel Morgan" <da******@x.was hington.edu> wrote in message
news:1089044573 .775113@yasure. ..

I was going to ignore this until I got to this paragraph. Oracle is
not 'incapable of true shared-nothing' ... it is designed with an
entirely different architecture and has no interest in trying shared
nothing.

Well actually Oracle was shared-nothing through version 5 or 6 but
rejected it because of the very issues we have beaten to death multiple
times so I'll no belabor the point again.

Suffice it to say that Oracle, like DB2 on mainframes, is a
shared-everything architecture by intent and no-one I am aware of with
experience with shared-everything has indicated any desire to return
to the bad old days.

--
Daniel Morgan

Well, aside from the fact that you quoted me incorrectly, I will say that
apparently Oracle could not make share-nothing work based on the existing
product they already had.

Share-nothing works best for large scalable data warehouses. Share
everything works best for 24x7 applications where failover and zero downtime
is extremely important. But even with share-nothing, most systems can be
brought back up in a few minutes, and their failover capabilities are
steadily improving. But in the end, one has chose which is more
important--scalability or failover.

I did say that Oracle's lack of share nothing did help it with failover
capabilities, but I think that DB2 is quickly catching up even with their
share-nothing architecture.

[Daniel Morgan]

Mark A wrote:

"Daniel Morgan" <da******@x.was hington.edu> wrote in message
news:1089044573 .775113@yasure. ..

I was going to ignore this until I got to this paragraph. Oracle is
not 'incapable of true shared-nothing' ... it is designed with an
entirely different architecture and has no interest in trying shared
nothing.

Well actually Oracle was shared-nothing through version 5 or 6 but
rejected it because of the very issues we have beaten to death multiple
times so I'll no belabor the point again.

Suffice it to say that Oracle, like DB2 on mainframes, is a
shared-everything architecture by intent and no-one I am aware of with
experience with shared-everything has indicated any desire to return
to the bad old days.

--
Daniel Morgan

Well, aside from the fact that you quoted me incorrectly, I will say that
apparently Oracle could not make share-nothing work based on the existing
product they already had.

An incorrect assumption. I didn't work in an environment where there was
a desire to have multiversion read consistency ... the ability to have
reads not block writes and writes not block reads. And it has far too
much overhead, in human hours, when adding or removing nodes. And it
decreases mean time between failure.

Don't try to invent reasons ... the reasons have been known and
published for more than a decade.
I did say that Oracle's lack of share nothing did help it with failover
capabilities, but I think that DB2 is quickly catching up even with their
share-nothing architecture.

We shall see. So far what I have seen still involves a parent or master
node that, if lost, causes a loss of service.

I have nothing against shared-nothing when implemented appropriately. My
problem was with what I interpreted as your statement that Oracle
couldn't implement it. Oracle did. Then threw it away.
--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.wash ington.edu
(replace 'x' with a 'u' to reply)

[Data Goob]

Daniel Morgan wrote:

Mark A wrote:

"Daniel Morgan" <da******@x.was hington.edu> wrote in message
news:1089044573 .775113@yasure. ..

I was going to ignore this until I got to this paragraph. Oracle is
not 'incapable of true shared-nothing' ... it is designed with an
entirely different architecture and has no interest in trying shared
nothing.

Well actually Oracle was shared-nothing through version 5 or 6 but
rejected it because of the very issues we have beaten to death multiple
times so I'll no belabor the point again.

I'd love to hear the reasons.
Suffice it to say that Oracle, like DB2 on mainframes, is a
shared-everything architecture by intent and no-one I am aware of with
experience with shared-everything has indicated any desire to return
to the bad old days.

Oracle is shared-everything? I thought it was just shared-disk.
--
Daniel Morgan
Well, aside from the fact that you quoted me incorrectly, I will say that
apparently Oracle could not make share-nothing work based on the existing
product they already had.

Not surprising.

An incorrect assumption. I didn't work in an environment where there was
a desire to have multiversion read consistency ... the ability to have
reads not block writes and writes not block reads. And it has far too
much overhead, in human hours, when adding or removing nodes. And it
decreases mean time between failure.

So it has nothing to do with the Oracle distributed lock manager?

Don't try to invent reasons ... the reasons have been known and
published for more than a decade.
And they are???

I did say that Oracle's lack of share nothing did help it with failover
capabilities, but I think that DB2 is quickly catching up even with their
share-nothing architecture.

We shall see. So far what I have seen still involves a parent or master
node that, if lost, causes a loss of service.

Have you used anything but Oracle?
I have nothing against shared-nothing when implemented appropriately. My
problem was with what I interpreted as your statement that Oracle
couldn't implement it. Oracle did. Then threw it away.

Hee-hee! :o)

I guess Oracle figured there was no need to scale beyond what, 8 servers
in a cluster?

[Daniel Morgan]

Data Goob wrote:

Oracle is shared-everything? I thought it was just shared-disk.
Then you thought 'wrong'.

Don't try to invent reasons ... the reasons have been known and
published for more than a decade.

And they are???

http://otn.oracle.com. Surely you don't need to be spoon fed.
Have you used anything but Oracle?
DB2, Informix, Sybase, Ingres, Teradata, COBOL, and Fortran on
punchcards.
I guess Oracle figured there was no need to scale beyond what, 8 servers
in a cluster?

10g scales to 128. The only place I can remember having an 8 node
limitation is on Solaris with Veritas. And the limitation is Veritas
not Oracle. Oracle scales to more nodes when Veritas is not used.

--
Daniel Morgan
http://www.outreach.washington.edu/e...ad/oad_crs.asp
http://www.outreach.washington.edu/e...oa/aoa_crs.asp
da******@x.wash ington.edu
(replace 'x' with a 'u' to reply)

[Larry]

Come on Daniel ... he means in reality. Don't quote theoreticals. How
many referenceable 128-node implementations of shared-everything,
shared-disk or whatever you want to call it ... does Oracle have?

Larry Edelstein

Daniel Morgan wrote:

Data Goob wrote:

Oracle is shared-everything? I thought it was just shared-disk.

Then you thought 'wrong'.

Don't try to invent reasons ... the reasons have been known and
published for more than a decade.

And they are???

http://otn.oracle.com. Surely you don't need to be spoon fed.

Have you used anything but Oracle?

DB2, Informix, Sybase, Ingres, Teradata, COBOL, and Fortran on
punchcards.

I guess Oracle figured there was no need to scale beyond what, 8
servers in a cluster?

10g scales to 128. The only place I can remember having an 8 node
limitation is on Solaris with Veritas. And the limitation is Veritas
not Oracle. Oracle scales to more nodes when Veritas is not used.

[Data Goob]

Daniel Morgan wrote:

Data Goob wrote:

Oracle is shared-everything? I thought it was just shared-disk.

Then you thought 'wrong'.

OK on Sun Starfire UE 10000 it's shared-everything, but is that on
all platforms? I think not--or would be very surprised if Oracle
on a typical 4-cpu or 8-cpu system could even work as shared-
everything. And my knowledge of Starfire is from a few years ago,
with Oracle 7 and 8. Intel is different hardware, and it is
questionable if Intel CPUs are even capable of the high-bandwidth
required to make SE work at the same levels as the Starfire--it's
not going to even approximate SE without the wheels coming off.
But I could be wrong...maybe it could work today. But big iron
systems are still very expensive, and a lot of shops can instead
cluster lower-end hardware and still get remarkable performance--to
wit the Opteron 2-cpu systems that DB2 can be clustered on with
shared-nothing.

Don't try to invent reasons ... the reasons have been known and
published for more than a decade.

And they are???

http://otn.oracle.com.

....
Surely you don't need to be spoon fed.

Can't argue with that. But I think it's important to note that
Oracle is not the same beast on all platforms, it cannot be exactly
the same on the Starfire as it would be on an Intel system, it
would simply not function the same.

Have you used anything but Oracle?

DB2, Informix, Sybase, Ingres, Teradata, COBOL, and Fortran on
punchcards.

I guess Oracle figured there was no need to scale beyond what, 8
servers in a cluster?

10g scales to 128. The only place I can remember having an 8 node
limitation is on Solaris with Veritas. And the limitation is Veritas
not Oracle. Oracle scales to more nodes when Veritas is not used.

Hmmmm, not what I read. Every time I hear about Oracle it's their
distributed lock manager that degrades over N servers. The more servers
the more complicated it gets.