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 system that 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-servers today) 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 really designed for it. I have seen misbehaving applications that would cause Oracle to spent over 30% of its processing time only with sending blocks back 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-downtime is 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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
