Is there a General Purpose Enterprise Solution?

Is there a General Purpose Enterprise Solution?

FB had no choice but to massively scale the MySQL database layer responsible for its user’s social graph. Neither MySQL nor the other SQL databases available at that time could solve this problem on their own. So, FB used its significant engineering might to essentially create a custom database query layer that abstracted the underlying sharded MySQL databases. In doing so, it forced its developers to completely give up on SQL as a flexible query API and adopt TAO’s custom NoSQL API.

Most of us in the enterprise world do not have Facebook-scale problems but nevertheless want to scale out SQL databases on-demand. We love SQL for its flexibility and ubiquity, which means we want to scale without giving up on SQL. Is there a general purpose solution for enterprises like us? The answer is Yes!

Hello Distributed SQL!

Monolithic SQL databases have been trying for 10+ years to become distributed in order to solve the horizontal scaling problem. As “Rise of Globally Distributed SQL Databases” highlights, the first wave of such databases were called NewSQL and included databases such as Clustrix, NuoDB, Citus and Vitess. These have had limited success in displacing manually sharded SQL databases. The reason is that the new value created is not enough to radically simplify the developer and operations experience. Clustrix and NuoDB mandate specialized, highly reliable, low latency datacenter infrastructure — modern cloud native infrastructure looks exactly the opposite. Citus and Vitess simplify the operations experience to an extent by auto-sharding the database but then handicap the developer by not giving him/her a single logical distributed SQL database.

We are now in the second generation of distributed SQL databases where massive scalability and global data distribution are built into the database layer as opposed to 10 years back when Facebook had to build these features into the application layer.

Inspired by Google Spanner

While FB was building TAO, Google was building Spanner, a completely new globally-consistent database to solve very similar challenges. Spanner’s data model was less of a social graph but more of a traditional, random-access OLTP workload that manages Google’s users, customer organizations, AdWords credits, GMail preferences and more. Spanner was first introduced to the world in the form of a design paper in 2012. It started out in 2007 as a transactional key-value store but then evolved into a SQL database. The shift to SQL as the only client language accelerated as Google engineers realized that SQL has all the right constructs for agile app development especially in the cloud native era where infrastructure is a lot more dynamic and failure-prone than the highly reliable private datacenters of the past. Today multiple modern databases (including YugabyteDB) have brought the Google Spanner design to life completely in open source.

Handling Internet-Scale Data Volume with Ease

Sharding is completely automatic in the Spanner architecture. Additionally, shards become auto balanced across all available nodes as new nodes are added or existing nodes are removed. Microservices needing massive write scalability can now rely on the database directly as opposed to adding new infrastructure layers similar to the ones we saw in the FB architecture. No need for an in-memory cache (that offloads read requests from the database thereby freeing it up for serving write requests) and also no need for a TAO-like application layer that does shard management.

Extreme Resilience Against Failures

A key difference between Spanner and the legacy NewSQL databases we reviewed in the previous section is Spanner’s use of per-shard distributed consensus to ensure each shard (and not simply each instance) remains highly available in the presence of failures. Similar to TAO, infrastructure failures always affect only a subset of data (only those shards whose leaders get partitioned away) and never the entire cluster. And, given the ability of the remaining shard replicas to auto-elect a new leader in seconds, the cluster exhibits self-healing characteristics when subjected to failures. The application remains transparent to these cluster config changes and continues to work normally without outages or slowdowns.

Seamless Replication Across the Globe

The benefit of a globally-consistent database architecture is that microservices needing absolutely correct data in multi-zone and multi-region write scenarios can finally rely on the database directly. Conflicts and data loss observed in typical multi-master deployments of the past do not occur. Features such as table-level and row-level geo-partitioning ensure that data relevant to the local region remains leadered in the same region. This ensures that the strongly consistent read path never incurs cross-region/WAN latency.

Full Power of SQL & Distributed ACID Transactions

Unlike the legacy NewSQL databases, SQL and ACID transactions in their complete form can be supported in the Spanner architecture. Single-key operations are by default strongly consistent and transactional (the technical term is linearizable). Single-shard transactions by definition are leadered at a single shard and hence can be committed without the use of a distributed transaction manager. Multi-shard (aka distributed) ACID transactions involve a 2-Phase Commit using a distributed transaction manager that also tracks clock skews across the nodes. Multi-shard JOINs are similarly handled by querying data across the nodes. The key here is that all data access operations are transparent to the developer who simply uses regular SQL constructs to interact with the database.

Summary

The data infrastructure scaling stories at any of the technology giants including FB and Google makes for great engineering learning. At FB, we took the path of building TAO which allowed us to preserve our existing investment in sharded MySQL. Our application engineers lost the ability to use SQL but gained a bunch of other benefits. Engineers at Google were faced with similar challenges but they chose a different path by creating Spanner, an entirely new SQL database that can horizontally scale, seamlessly geo-replicate and easily tolerate infrastructure failures. FB and Google are both incredible success stories so we cannot say that one path was better than the other. However, when we expand the horizon to general-purpose enterprise architectures, Spanner comes ahead of TAO because of all the reasons highlighted in this post. By building YugabyteDB’s storage layer on the Spanner architecture, we believe we can bring the developer agility of the technology giants to the enterprises of today.

What’s Next?

• Compare YugabyteDB in depth to databases like CockroachDB, Google Cloud Spanner and MongoDB.
• Get started with YugabyteDB on macOS, Linux, Docker and Kubernetes.
• Contact us to learn more about licensing, pricing or to schedule a technical overview.

AUGUST 29, 2017