On 3/25/16, 4:37 AM, "pgsql-general-ow...@postgresql.org on behalf of Mark Morgan Lloyd" <pgsql-general-ow...@postgresql.org on behalf of markmll.pgsql-gene...@telemetry.co.uk> wrote:
>Jernigan, Kevin wrote: >> On 3/22/16, 8:07 AM, "Bruce Momjian" <br...@momjian.us> wrote: > >>> >>> 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 <br...@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 capability from any other relational db >> engine, until the release of IBM DB2 Shareplex a few years ago. And given >> the improvement of PostgreSQL and other open source solutions over the past >> 20 years, it’s not clear that it makes sense to go through the initial >> design and implementation work and then the ongoing maintenance overhead - >> most of what RAC provides can be achieved through other existing >> capabilities. > >Hearing what IBM's strong points are is always useful, since the various >flavours of DB2 obviously have facilities to which other databases >should aspire. As with Oracle, DB2's strong points aren't really >well-publicised, and things are further complicated by the variant >terminology which IBM has evolved over the half century they've been >building mainframes. > >> 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 >> streaming replication: the overhead of synchronous replication limits >> scalability, and the failover time for moving from primary to 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 better for certain high-end extreme >> workloads - and maybe I can’t even win those arguments ;-) - the real issue >> is that there aren’t very many of those workloads, and the PostgreSQL >> community shouldn’t care: the vast majority of Oracle (and SQL Server etc) >> workloads don’t need all the fancy high-end RAC capabilities, or many of the >> other high-end commercial database capabilities. And those workloads can >> relatively easily be migrated to PostgreSQL, with minor disruption / change >> to schemas, data, triggers, constraints, procedural SQL… > >What I've seen so far suggests that if MS is positioning SQL Server to >challenge Oracle, it's basically looking for low-hanging fruit: in >particular supplementary databases which corporates have put onto Oracle >out of habit but which quite simply don't need some of the higher-end >facilities for which Oracle is harvesting revenue. > >Just because a corporate has a hundred sites cooperating for inventory >management doesn't mean that the canteen menus have to be stored on >Oracle RAC :-) > Right, but often the customer has paid for a site license, in which case the IT department will just keep spinning up more Oracle (or SQL Server or DB2) databases when requests come in - even if it’s overkill for the proposed use case / workload, it’s less work if IT only has one database technology to support. For all kinds of often cloud-y reasons, there have been recent stories in the press of many enterprise customers not renewing their site licenses, in favor of cherry-picking their biggest / hardest workloads for the commercial databases, and then moving the rest to open source, often though not always to PostgreSQL, and often in the cloud. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
