Google Spanner: The Good and the Better

Google's Impressive New Tech: Cloud Spanner

Google just announced their Beta Cloud Spanner, a “horizontally scalable, globally consistent, relational database service.” This impressive hosted technology addresses a long-standing market request: “How can we make our SQL databases scale both writes and reads past a single server?” This is the very important difference between “scale up” and “scale out.” Can adding additional database servers add write scale? Or do those additional servers just add read scale? MySQL “read slaves” (MySQL, MariaDB, Percona, etc), and Amazon Aurora “read replicas” only provide read scale.

The Challenge of Scaling Writes

Adding additional write scale--once you’ve migrated your database to the biggest server available--usually requires some version of “sharding.” This means your data tables get partitioned across multiple different database servers, i.e., separate RDBMSs. This allows each subset of your data to enjoy the full write and read horsepower of its own server. However, this means cross-partition (“shard”) transactions don’t have a coordinating RDBMS to guarantee ACID and referential integrity. Either your application loses that level of transactional robustness, or your application stack needs to rebuild those guarantees the database (shards) can no longer provide. Finally, data rebalancing across the array of shards is an ongoing maintenance requirement. Many production sharded databases need to schedule periodic downtime to redistribute the data to ensure storage capacity and avoid hotspots.

Best of Breed Technology

Google originally started building Spanner for their own internal use when they realized that continuing to add shards to their internal MySQL sharding arrays was no longer sustainable.

Leveraging tried and true technologies like two-phase locking (2PL) and multi-version concurrency control (MVCC) for transactional commit consistency, and Paxos for consensus across database servers, Spanner also leverages state-of-the-art technology such as atomic clocks. Installed in each data center supporting Spanner, the atomic clocks are used to “keep uncertainty small” (generally less than 10ms).

The result is a database that aims to provide the horizontal scale out of NoSQL while providing the relational consistency of an RDBMS. This type of database has been called “NewSQL” and can be quite the game changer for those who have SQL RDBMS databases and need scale. Google’s NewSQL database Spanner promises multi-region horizontal scale (1000s of servers) with ACID cross-node transactions, high performance, SQL compatibility, and 99.999% availability. However, to get the horizontal scale out of NoSQL, NoSQL databases lose ACID cross-node transactions. So what’s the compromise with Spanner?

Spanner’s Latency

Spanner provides cross-node transactions with ACID guarantees, but the more nodes you add (i.e., “participants” in the below chart), the more latency climbs:

This means the more you scale out, the slower your transactions will become. The very pitfall of NoSQL, cross-node JOINs, don’t perform as badly with Spanner, but they don’t perform as quickly as a single-server SQL RDBMS either.

ClustrixDB: Non-Beta MySQL-compliant Scale-out RDBMS

There is another NewSQL scale-out RDBMS that provides write scale, cross-server ACID transactional guarantees, high performance, and low latency. ClustrixDB, like Spanner, leverages 2PL and MVCC for transactional commit consistency, and Paxos for consensus across database servers. Similarly, ClustrixDB automatically distributes and balances the data across all the database nodes in the cluster, as well as provides a single logical database for the application to connect to. The application doesn’t need to know it’s accessing a multi-server scale-out RDBMS; it can simply send transactions and the data access and distribution is handled behind the scenes transparently.

More importantly, instead of using custom client libraries, ClustrixDB is completely MySQL compliant. Simply import your MySQL dumpfile, point your application endpoint to ClustrixDB, and ClustrixDB will handle your MySQL workload at scale.

Most importantly, ClustrixDB is not beta, but a production-ready database that is deployed with hundreds of customers around the world, some of which are among the largest of their industry (i.e., e-commerce, social, mobile). You can run ClustrixDB on any cloud or in your own data center, avoiding vendor lock-in.



Follow Clustrix

twitter      linkedin      facebook      youtube

Visit our resources or documentation
page for further reading.