Google's Cloud Spanner To Settle the Relational vs NoSQL Debate?
Written by Nikos Vaggalis
Tuesday, 28 February 2017
Cloud Spanner is a new proposition for database as a service that emphatically offers "Relational with NoSQL scaling". Will Google come to dominate yet another market?
Once upon a time there was only one kind of database management system, the RDBMS, "R" for relational. Despite its resilience and trustworthiness, it had its shortcomings; it did not scale well, and the relational model it served proved inadequate in the dawn of the Big Data era for handling massive amounts of schema-less, unstructured data.
For this and a few other reasons, a new breed of DBMS's emerged, one that could handle the avalanche of big data, based on the notion of the key-value pair, and doing so by scaling horizontally. But, in order to become versatile, this new breed of management systems had to forgo the safety of the ACID and the cosiness of SQL, both long term partners of the relational model.
Of course, there were many attempts to bridge the two; adding SQL capabilities to Hadoop's HBase via, say, Apache Phoenix, or granting PostgreSQL JSON capabilities, but these were still compromises rather than innovations. Fusions, like Splice Machine, see First Hybrid Open-Source RDBMS Powered By Hadoop and Spark, are a novel attempt to merge the best parts of the traditional relational database management systems and their NoSQL counterparts, thus enabling true RDBMS's with MVCC and ACID on systems such as Hadoop, capable of doing real-time on-the-fly analysis and updates on massive and distributed data volumes.
But now the time has come for Google to get its slice of the pie in the hybrid database market. With Cloud Spanner, Google claims to have developed:
a globally distributed relational database service that lets customers have their cake and eat it too: ACID transactions and SQL semantics, without giving up horizontal scaling and high availability
It's a statement that should be self evidently be true because internally, Cloud Spanner backs up many well-known Google applications, such as Gmail, Google Photos, Calendar, Android Market, and AppEngine, available to the public at large and once relying on a Megastore backend. Furthermore, Google looks into to commercializing the platform by offering it as a DBaaS available for rent, along the lines of Amazon AWS Aurora or Microsoft's Azure DocumentDB, the difference being that it runs on Google's own private global network.
Architecturally, while not a key value store according to the NoSQL standard, albeit resembling one, Cloud Spanner is not purely relational. It's rather semi-relational, hoisting a similar schema language, in that every table is required to have an ordered set of one or more primary-key columns, being the requirement that makes it look like a key-value store:
the primary keys form the name for a row, and each table defines a mapping from the primary-key columns to the non-primary-key columns. A row has existence only if some value (even if it is NULL) is defined for the row’s keys. Imposing this structure is useful because it lets applications control data locality through their choices of keys.
The other distinct Cloud Spanner characteristic is its use of GPS and atomic clocks to coordinate its distributed nodes via TrueTime, a service that uses a network of globally synchronized clocks to enable consistent replication across datacenters.
It's obviously an ecosystem addressed to big clients that rely on coordinated, distributed, fail-safe, ACID transactions throughout a global infrastructure network.This is also being reflected in the flexible pricing model in place, which varies depending on the:
number of Cloud Spanner nodes in your project.
amount of storage that your tables and secondary indexes use.
amount of network bandwidth used.
As such, Cloud Spanner propels Google as a heavyweight player into an already congested DataBase as a Service market; the question now is, are the advertised capabilities going to really make such a difference as to place Google ahead of the competition?
In a surprise announcement, the Android development team has made it clear that the new Jack compiler and Jill linker are not going anywhere. The move to Java 8 will now be made by developing the exis [ ... ]