Google has officially released its Cloud Spanner to the public, a regional database service that they’ve been using for many years. Google claims that this is the “first and only relational database service that is both strongly consistent and horizontally scalable.”
What makes Cloud Spanner different?
Essentially, Google has made it so database administrators don’t have to choose anymore. As projects get larger, it becomes a decision between a database that allows for large scaling, as well as data distribution like NoSQL, or one that gives transactional consistency.
Now, it’s possible to have both in one fully managed service. Admins and developers want the advantages of both global scalability and consistency, and this is what Spanner is built to give.
In addition, Google knows that many users would switch to Spanner while scaling up from a different service, so it has measures in place to make the transition simple. For example, admins won’t need to start from the beginning to learn different syntax. Instead, Cloud Spanner uses SQL syntax and offers ACID transactions, so most prior knowledge would easily transfer over.
So, Cloud Spanner gives users everything that they expect out of a relational database, such as ACID transactions, relational schemas or schema changes without downtime, SQL semantics, high performance, and high availability.
In addition to the traditional features, Spanner also scales horizontally. This means that it is able to function with the highest of transactional workloads through scaling to hundreds or thousands of servers.
According to Google, “With automatic scaling, synchronous data replication, and node redundancy, Cloud Spanner delivers up to 99.999% of availability for your mission critical applications.”
As they say, the proof is in the pudding. One of the ways Google verifies this claim about Cloud Spanner is the fact that their internal Spanner service has, in fact, handled millions of queries per second for multiple Google services for many years now.
So, Cloud Spanner is likely a great alternative for those developers who need to move past traditional regional databases and their limits, but keep all of the features. With a practically endless limit for scalability and ability to perform global transactions, Cloud Spanner could be a good option for both large and small databases.
If you’re a developer with a system such as MySQL or PostgreSQL that is unable to scale to your needs, or you can’t handle a database without consistency that requires hand-rolled transactions, Cloud Spanner might be your solution.
Why did Google create Cloud Spanner?
Cloud Spanner has actually been around for quite some time. Google was tired of choosing between two databases for features that they wanted included, so they created both major features in one option.
Traditional databases were able to build applications that sufficiently met the needs of those who didn’t require large scalability and featured a relational data model and SQL queries. NoSQL solutions, on the other hand, were able to handle very large scale with quick data-processing but lacked the traditional database’s consistency.
Considering this, engineers and researchers at Google strove to find a solution for this that was globally-distributed back in 2007. The Spanner research paper reached the outside world in 2012, and after years of internal tests around the world, it’s finally available to the public.
Also listed on Google’s blog, Cloud Spanner “supports tens of millions of queries per second and runs some of our most critical services, including AdWords and Google Play.”
Digging into the features of Cloud Spanner
Scale and consistency
As mentioned, its main selling point is that there is no more need to choose between scale and consistency. Cloud Spanner serves data with “single-digit millisecond latencies” while it holds onto transactional consistency and high availability.
It scales horizontally within regions and plans to expand to cross-region replication later this year, and there’s no need for migration from relational to NoSQL databases while scaling. The reason users will flock to Spanner is that there’s no need for complex sharding or clustering while scaling out.
No need to worry about infrastructure
Cloud Spanner is already fully managed and built for the cloud, so IT resources won’t need to spend their time managing the hardware and software.
Cloud Spanner has automatic synchronous replication and sharding, so more of your time can be invested in the actual application or scaling out your RDBMS solutions. They guarantee high availability and disaster protection for all of your applications without the time investment in engineering things such as failover infrastructure.
Security and default encryption
Google has a pretty iffy history on privacy, but its security usually stands up against the tests. With Cloud Spanner, you’re given a whole host of tools created and tested by Google, many of which have already been in use for years.
With Spanner, you get Google’s default encryption in transit and at rest so you can feel secure with your data. Additionally, they offer “granular identity and access management, comprehensive audit logging, custom-manufactured hardware, hardware tracking and disposal, and the Google-owned ad controlled global network.”
There are quite a few applications working to keep your data secure. Feel free to check out Google’s Infrastructure Security Design Overview if you’re interested in a more in-depth look at this portion of Cloud Spanner.
Available for multiple languages
Cloud Spanner lets developers stick to what they know best by keeping the tools and environment simple and similar to what they’re used to. This application supports “distributed transactions, schemas and DDL statements, SQL queries and JDBC drivers.” Not only this, but client libraries are available for many popular programming languages, like Java, Go, Python, and Node.js.
Cloud Spanner has a pricing model that charges you only for what you use, scaling up or down as necessary. Essentially, you are charged for the number of Cloud Spanner nodes you have in your project, how much storage you consume with your tables and secondary indexes use, and the amount of network bandwidth used.
The cost per node per hour is $0.90, storage per GB per month is $0.30, and network rates vary by location and amount used. For more details, check out the pricing section of their website. If you already have an idea of the details of your project, use this pricing calculator to get a better idea.