Chapter 2. Distributed Databases
A lot has changed since the term “relational database” was first coined in 1970. Legacy relational database management systems (RDBMSs) brought with them ACID compliance but were operating in a pre-cloud world and so were not built to be horizontally scalable. HBase, inspired by Google’s 2006 Bigtable whitepaper, was created by Powerset in 2008, followed a couple of months later by Cassandra from Facebook. Both provided the ability to scale larger than any RDBMS had done before but at the cost of ACID compliance.
It wasn’t until the Spanner whitepaper was published in 2012 that the concept of a natively distributed RDBMS became a reality. In 2015, CockroachDB entered the database stage and brought with it the possibility for ACID compliance at a global scale.
With the ability to now scale a relational database far beyond what was previously possible, the following capabilities are now available:
-
Expand your business into global markets with one database
-
Scale up and down depending on demand
-
Survive disasters arising from node, AZ, region, or even entire CSP failures
Considerations When Using a Distributed SQL Database
The challenges of running a distributed SQL database differ from those of running a traditional database. Let’s compare.
We’ll start with traditional databases:
- Resilience
-
With databases, such as MySQL, Postgres, and databases built atop these technologies, such as AlloyDB, AWS Aurora, etc., you’re typically writing to ...
Get Understanding Multi-Region Application Architecture now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.