Which is worse...?
One of your users goes to check her bank balance in your app, and the service is down,
One of your users goes to check her bank balance in your app and there's a data inconsistency.
Engineers are frequently faced with this false tradeoff: do you place a higher premium on data correctness, or high availability? This problem only becomes more complicated when you begin dealing with users distributed across broad geographies.
When IT experts consider high availability infrastructure for mission-critical services, their minds often leap to Oracle as the preeminent service provider. But Oracle's database was designed in a pre-cloud world, and the means by which it achieves high availability on geo-distributed workloads are complex. Oracle requires a staggering number of technologies that must be implemented, and still, their solutions can allow potentially costly anomalies into your data.
As a cloud native database, CockroachDB introduces a new way of providing always-on availability, strong data consistency, and distributed performance.
Today, we're releasing a side-by-side comparison of CockroachDB and Oracle to help you get a better understanding of the architecture (and cost) of setting up a highly available distributed service.
Overview of high availability features
Here's a quick side-by-side comparison of the tools you need to create a high-availability architecture using Oracle vs. CockroachDB. We chose to focus on these features because they represent the majority of what teams need to guarantee high availability.
First, you need to make sure you can replicate data within a single site to survive individual machine failures. Next, to survive an entire site going down, you need to scale and replicate data across regions. In widely distributed deployments, you might want to optimize your application's performance by controlling your data's physical layout. And lastly, every team needs a good disaster recovery plan--just in case.
|Scale & HA at one site||RAC, disk management ($$)||Included in database binary|
|Intra-site networking||Private Interconnect ($$)||Included in database binary|
|Intra-site replication||Distributed Lock Storage ($$), CacheFusion ($$)||Included in database binary|
|Scale across-sites||GoldenGate ($$)||Included in database binary|
|HA & Inter-site routing||Global Data Service ($$)||Edge tool (OSS options available)|
|Control data's physical layout||Configurable via GoldenGate ($$)||Table-level: Included in database binary Row-level: Geo-partitioning ($$)|
|Disaster Recovery||Non-Distributed: RMAN||Non-Distributed: Included in database binary
($$ denotes features you must obtain a paid license to use in a production environment.)
As you'll read in our guide, Oracle requires a separate tool for almost every HA feature––and all but one of them (RMAN) requires its own enterprise license. CockroachDB, on the other hand, has options to be run in production with no licensing costs. For those with more complex needs, we offer more robust enterprise-grade tools with a license.
While this overview can help contextualize some of the bewildering complexity Oracle introduces into your infrastructure, we have a more comprehensive guide to high availability architecture available here for you to check out.
The post Introducing the High Availability Architecture Guide (CockroachDB vs. Oracle) appeared first on Cockroach Labs.