Re: PostgreSQL advocacy - Mailing list pgsql-general

From Thomas Kellerer
Subject Re: PostgreSQL advocacy
Date
Msg-id ncp24o$hp7$1@ger.gmane.org
Whole thread Raw
In response to PostgreSQL advocacy  (Mark Morgan Lloyd <markMLl.pgsql-general@telemetry.co.uk>)
Responses Re: PostgreSQL advocacy  (Rakesh Kumar <rakeshkumar464a3@gmail.com>)
List pgsql-general
Mark Morgan Lloyd schrieb am 21.03.2016 um 14:44:
> I was discussing this sort of thing elsewhere in the context of MS's
> apparent challenge to Oracle and IBM, and the dominant feeling
> appeared to be that actual use of things like Oracle RAC was
> vanishingly uncommon. Which surprised me, and which I'm treating with
> caution since the fact that facilities aren't used (in a certain
> population of developers etc.) can in no way be interpreted as
> meaning that the technology is not unavailable or unreliable.

RAC is usually used for high-availability not for (horizontal) scaling.

All nodes in a RAC cluster share the same I/O system. So I/O is still the bottleneck and you can't use a RAC to scale a
systemthat is I/O bound.  

Back in the days when RAC was introduced multi-core, multi-CPU servers weren't that common (and and way fewer CPUs as
high-serverstoday) and for systems like that, RAC _can_ indeed be used to scale the system.  

And the cache synchronization across the nodes can quickly become a *serious* bottleneck if the application isn't
reallydesigned for it.  
I have seen misbehaving applications that would cause Oracle to spent over 30% of its processing time only with sending
blocksback and forth between the nodes. 

So - at least as far as I can tell - it's usually only used where high-availability is really important, e.g. where
zero-downtimeis required.  
If you can live with a short downtime, a hot standby is much cheaper and probably not that much slower.

See e.g. here: http://www.sdmc.nl/YouProbablyDontNeedRACUSVersion.pdf
and here:
http://nyoug.org/Presentations/2006/September_NYC_Metro_Meeting/200609Zito_You%20Probably%20DO%20Need%20RAC.pdf

Thomas


pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: Including SQL files
Next
From: Alexander Farber
Date:
Subject: Re: Including SQL files