- Use Cases
- Dev Center
- Watch the Demo ❯
You are here
Google Cloud Spanner & AdWords: The Pattern for Modern Database Applications
Feb 15 2017
If you are like me, then Google searches have been part of your life for 15 years or more. In that time, Larry Page’s “BackRub” project has developed into part of everyday life. Google’s announcement of the the Beta release of the Cloud Spanner database system is a good time to stop and contemplate some of the technology involved in delivering results to a search query.
Spanner uses the same underlying database technology for Google AdWords, which frankly is really a big deal in the database world. Google is now launching Spanner-as-a-service, called “Cloud Spanner.” In my view, Cloud Spanner is more important than any of the very good database systems that are already running on the Amazon, Azure, IBM, Google, and other clouds. And Cloud Spanner is certainly at a completely different level to traditional database systems like Oracle or MongoDB. Here is how Google summarizes that importance:
[Cloud Spanner] lets customers have their cake and eat it too: ACID transactions and SQL semantics, without giving up horizontal scaling and high availability.”
Perhaps the best way to understand the point is to take a look at Google AdWords, the application responsible for the majority of Google revenue. Consider for a moment what goes on when you issue a Google search query. Within a half-second of kicking off a search, I get a results page. That’s impressive, but take note that Google also provided me with some relevant ads. To do this, Google AdWords had to:
- Do a content-based prioritization of possible ads to display
- Analyze the $$$ bids by relevant advertisers
- Apply rules about time of day and location
- Incorporate add quota constraints
- And if the user clicks on the ad, then record a financial transaction for billing and optimization purposes
That’s not all. It has to be done for millions of concurrent users in thousands of locations simultaneously. It also has to be done reliably, not least because this has been the primary revenue stream for Google. AdWords is really impressive technology. To a database person it is an extreme example of what Gartner calls Hybrid Transactional/Analytic Processing (HTAP).
This kind of workload cannot be handled by traditional RDBMS or NoSQL database technologies, so to address the AdWords requirement Google built F1, a database service that is layered on Spanner. In the F1 Whitepaper, Google makes it clear that a new type of database system was required:
On Traditional SQL:
“[Google F1] was designed to replace a sharded MySQL implementation that was not able to meet our growing scalability and reliability requirements.”
“Instead of going NoSQL, we built F1, a distributed relational database system that combines high availability, the throughput and scalability of NoSQL systems, and the functionality, usability and consistency of traditional relational databases, including ACID transactions and SQL queries.”
Google’s description of Spanner is here. It is all about what we call Elastic SQL, the idea that you can run SQL applications of similar complexity, reliability and manageability to what your traditional RDBMS can handle but with the ability to scale-out and scale-in on elastic infrastructure. That elasticity gives you dynamic capacity management, continuous availability, multi-datacenter operation and radical operational simplicity. It’s what Google calls “having your cake and eating it too”.
Here is a Google table that compares Cloud Spanner (Elastic SQL) capabilities with Traditional Relational and Non-relational database systems:
Cloud Spanner also addresses the challenge of Eric Brewer’s “CAP Theorem”. Eric works for Google of course, and he wrote up a description of Spanner and CAP. It’s good to see pragmatic thinking applied to the topic.
The above really summarizes the overall point. There have been a lot of voices in the database industry suggesting that your choice is between scale-out and SQL or between well defined schemas and data model flexibility. Google is saying you can have it all. It’s not a choice between breathing out and breathing in - you can do both.
Certainly, we at NuoDB would entirely agree with the position Google is taking with Cloud Spanner. If you can deliver a true Elastic SQL database system then users get the best of both worlds: The power of SQL/ACID transactions, along with dynamic provisioning, always-on operation, and modern administration.
NuoDB and Cloud Spanner have a lot in common but there are also some important differences in design goals and technical architecture. As it relates to design goals, Google is naturally offering Cloud Spanner as part of delivering the Google Cloud Platform. We at NuoDB are focused on what we call the “cloud on-ramp”, which is about helping enterprises and software vendors to move to elastic infrastructures incrementally.
Whether you ultimately want to run on a public cloud, on an on-prem cloud, or are targeting a hybrid deployment, NuoDB offers you Elastic SQL capability on your chosen platform. Many of our customers don’t really know where they want to deploy longer term, or for how long they would want to commit to an IaaS vendor. But they do know that they need to architect and/or migrate their SQL applications to run on some kind of elastic infrastructure.
Take for example Kodiak, a provider of software to telco companies. Kodiak is singularly focused on providing highly reliable, highly scalable, standards-based broadband push-to-talk (PTT) solutions for their carrier partners. They needed a database that could support the application code they have already developed. In the words of their co-founder and chief product officer Bruce Lawler, "NuoDB was the best database to support our need for scaling up our distributed network to meet demand requirements while maintaining transactional consistency and integrity.”
For Movemedical, the decision to switch to NuoDB’s elastic SQL database was driven by the need to maintain a cloud application that is always available and extremely responsive. Their previous database was a traditional one that was extremely challenging to scale.
Toan Truong, Lead Systems Engineer at Movemedical has said, "Unlike our previous database, adding more capacity in NuoDB - whether it’s within a single instance or across our globally distributed data centers - is extremely fast and simple. Using NuoDB has enabled us to maintain our SQL interface and preserve ACID compliance, while achieving the elastic scale and continuous availability we need.”
Even our smaller customers are looking for this “perfect combination of traditional relational databases and NoSQL databases” (in the words of Walid Darwish, co-founder & CTO of CauseSquare). "We not only get a database that can maintain exceptionally high availability, we also can easily (and cost-effectively) add capacity when we need it without compromising on transactional consistency or data durability.”
We expect next-gen applications like the ones these customers provide to have AdWords-like requirements, including rich SQL support, ACID transactional guarantees, and elastic behavior on scale-out datacenters. As Google have indicated, Elastic SQL databases like Cloud Spanner and NuoDB are essential pieces of that puzzle.
Cloud Spanner is evidently a very powerful piece of technology, destined no doubt to be a big part of the Google Compute Platform. We are truly excited to see that Elastic SQL databases are becoming a reality, and specifically that Google is making the Cloud Spanner service available to users.
For more information on how NuoDB and Cloud Spanner compare, read our latest tech blog!
Barry Morris is a co-founder and the executive chairman at NuoDB, where he chairs the Board of Directors and drives the external matters of NuoDB, including industry thought leadership, strategic partnerships, and business relationships as well as product and technology strategy. He also serves as an advisor to the CEO and senior leadership on all aspects of the business.