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 :-)
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
