Google just made it’s internal DB called Spanner open to public via it’s cloud offerings couple of days ago, and it’s already being touted as somewhat of a game changer. But is it really?
So basically there is this term CAP, often referred to as the CAP Theorem, that is an acronym for Consistency, Availability and Partition Tolerance. Consistency refers to the idea that all data in every node and cluster should have the same value at a given point in time. Availability signals at 100% uptime for both read and write executions. And partition tolerance refers to whether the database continues to function correctly if communication between servers is interrupted for some reason. Now, CAP Theorem says you can have only two of the three, and must sacrifice the third. Basically, you can either have CA, CP or AP. But not all three simultaneously.
It’s always been about A
Now, the person who initially coined the CAP Theorem was Eric Brewer of Google. He just wrote an article yesterday on valentines (a true romantic) where he claims that it’s always been about A. That is that 100% availability has always been the most important of the trinity. You can live with outdated data, as long as some data, even if its not the most recent, returns successfully.
How Google Beat Time
In a truly distributed database, where you have data centers strewn across the world, having real time or near real time consistency has been an issue. The reason Spanner is making waves the last few days is basically due to the claim that Google has been able to somehow bend time. How have they done that? Basically by developing an advanced and sophisticated timekeeping mechanism. It uses GPS receivers and atomic clocks to keep its own track of time rather than depending on NTP. Google calls this TrueTime. A key factor in achieving this hyper accuracy is the fact that Spanner runs on Google’s private network. Google not only has a global footprint like no other company, but also runs and controls its own WAN.
RDBMS vs. NoSQL vs. Spanner
Typically relational databases (RDBMS) like SQL Server, Oracle, MySQL, etc. scale-up. That is you can throw more RAM and processing power at them. Problem is at one point, you reach a limit. NoSQL databases get around this by scaling-out i.e. adding more servers or nodes. Problem with that then becomes synchronization and consistency. So NoSQL databases like Cassandra have specialized replication algorithms where nodes send each other updates to keep data fresh and synchronized between updates. Well, Spanner basically brings the relational quality of RDBMS with the distributed architecture of the NoSQL database. In Brewer’s own words:
Spanner is Google’s highly available, global SQL database. It manages replicated data at great scale, both in terms of size of data and volume of transactions. It assigns globally consistent real-time timestamps to every datum written to it, and clients can do globally consistent reads across the entire database without locking.
But is it really? Is it?
Strictly speaking, no you cannot have 100% availability. What Spanner claims you can have though is near 100% availability, with near consistency, while operating over a wide area network. But that near may be just good enough. Google claims that Spanner offers five 9s availability meaning less than 1 in 10^5 calls. That is good enough for a lot of businesses.
Is Spanner the DB Holy Grail?
I think that remains to be seen. What will make a difference is that now that near CAP is possible, do companies really need it? If you are a multinational running global operations, are you going to be ok with other NoSQL choices like MongoDB and Cassandra or even running local scaled-up RDBMS that are cut up by regions and business units? Do business really need all three tenants of CAP, or is it just a cool bit of technology.