Jonah H. Harris schrieb:
On 9/29/05, *Tino Wildenhain* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Well, I dont know why many people believe parallel execution
automatically means high performance. Actually most of the time
the performance is much worser this way.
If your dataset remains statically and you do only read-only
requets, you get higher performance thru load-balancing.
If howewer you do some changes to the data, the change has to
be propagated to all nodes - which in fact costs performance.
This highly depends on the link speed between the nodes.
I think you should clarify that the type of clustering you're discussing
is the, "shared-nothing" model which is most prevalent in open-source
databases. Shared-disk and shared-memory clustered systems do not have
the "propagation" issue but do have others (distributed lock manager,
etc). Don't make blind statements. If you want more information about
"real-world" clustering, read the research for DB2 (Mainframe) and
Oracle RAC.
No, thats not a blind statement ;) It does not matter how the
information is technically shared - shared mem must be
copied or accessed over network links if you have more then
one independend system. Locks are informations too - thus the
same constraints apply.
So no matter how you label the problem, the basic constraints:
read communication and synchronisation overhead will remain.
Costom solutions can circumvent some of the problems if you
can shift the problem area (e.g. have some read-only areas,
some seldom-write areas and some high write, some seldom read
and not immediately propagated data)
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
