Re: PostgreSQL advocacy - Mailing list pgsql-general

On 3/22/16, 8:07 AM, "Bruce Momjian" <bruce@momjian.us> wrote:



>On Mon, Mar 21, 2016 at 04:46:51PM +0000, Jernigan, Kevin wrote:
>> Disk is only a single point of failure in RAC if you configure
>> non-redundant storage. In general, Oracle recommends triple mirroring
>> to protect against disk failures, as they have had many experiences
>> over the years where customers with mirrored disks would see
>> consecutive disk failures within short periods of time.
>>
>> And RAC is widely used by Oracle’s larger customers, not only
>> for HA, but also in some cases for scale-out. Having said that,
>> it’s very true that any application running on Oracle RAC must be
>> configured to avoid hot block contention across RAC nodes, so it’s
>> not a completely transparent solution for scale out.
>
>I get asked about Oracle RAC often.  My usual answer is that Oracle RAC
>gives you 50% of high reliability (storage is shared, mirroring helps)
>and 50% of scaling (CPU/memory is scaled, storage is not).  The
>requirement to partition applications to specific nodes to avoid cache
>consistency overhead is another downside.  (Slide 24 of my scaling
>presentation shows Oracle RAC,
>http://momjian.us/main/writings/pgsql/scaling.pdf .)
>
>I said the community is unlikely to go the Oracle RAC direction because
>it doesn't fully solve a single problem, and it is overly complex.  The
>community prefers fully-solved problems and simpler solutions.
>
>For me, streaming replication fully solves the high reliability problem
>and sharding fully solves the scaling problem.  Of course, if you need
>both, you have to deploy both, which gives you 100% of two solutions,
>rather than Oracle RAC which gives you 50% of each.  
>
>However, I do think database upgrades are easier with Oracle RAC, and I
>think it is much easier to add/remove nodes than with sharding.  For me,
>this chart summarizes it:
>
>                         HA   Scaling  Upgrade Add/Remove
>        Oracle RAC       50%     50%    easy    easy
>        Streaming Rep.  100%     25%*   hard    easy
>        Sharding          0%    100%    hard    hard
>        
>        * Allows read scaling
>
>-- 
>  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
>  EnterpriseDB                             http://enterprisedb.com
>
>+ As you are, so once was I. As I am, so you will be. +
>+ Roman grave inscription                             +

Implementing RAC-equivalent functionality is extremely hard, as evidenced by the lack of any directly comparable
capabilityfrom any other relational db engine, until the release of IBM DB2 Shareplex a few years ago. And given the
improvementof PostgreSQL and other open source solutions over the past 20 years, it’s not clear that it makes sense to
gothrough the initial design and implementation work and then the ongoing maintenance overhead - most of what RAC
providescan be achieved through other existing capabilities. 
 

While I’m not sure that the percentage breakdowns in your chart are totally accurate, I agree with the general
assessment,except for the highest-end applications which have zero-downtime requirements which can’t be met with
streamingreplication: the overhead of synchronous replication limits scalability, and the failover time for moving from
primaryto a failover target is significantly slower than RAC - which can be literally zero if configured correctly.
 

The higher-level point that I think is important is that while I may be able to win technical arguments that RAC is
betterfor certain high-end extreme workloads - and maybe I can’t even win those arguments ;-) - the real issue is that
therearen’t very many of those workloads, and the PostgreSQL community shouldn’t care: the vast majority of Oracle (and
SQLServer etc) workloads don’t need all the fancy high-end RAC capabilities, or many of the other high-end commercial
databasecapabilities. And those workloads can relatively easily be migrated to PostgreSQL, with minor disruption /
changeto schemas, data, triggers, constraints, procedural SQL…
 

-KJ