Switching to Spanner – Scaling Up
Google Cloud Spanner is Google’s fully managed, scalable, relational database service. Cloud Spanner is designed to offer the transactional consistency of a traditional relational database plus the scalability and performance of a NoSQL database.
Unlike Cloud SQL, Cloud Spanner is cloud native and can scale horizontally and globally. Although it can be very expensive, it is a good fit for large-scale applications. While it is certainly overkill for the fact service at the moment, it is useful to demonstrate how to use it and how switching from Cloud SQL is possible.
The cloud-agnostic version of the fact service used in this chapter knows nothing about Google Cloud. Although it connects to a Cloud SQL database, it connects through a proxy. As far as the Spring application is concerned, there is a PostgreSQL instance running on the local host it can talk to using the PostgreSQL wire protocol. The Cloud SQL Proxy is taking care of all the networking, encryption, and authentication required.
While you can connect to Cloud Spanner natively using client libraries, it is also possible to connect to Cloud Spanner via a proxy, similar to how you have with Cloud SQL. The PGAdapter provides a PostgreSQL-compatible interface to Cloud Spanner, as again the client application can treat it as a PostgreSQL database running on the localhost. There are several different options for running the PGAdapter as a standalone Java process, a Java library, or a Docker container. As the fact service uses Kubernetes, the easiest is to use the Docker image provided by Google as a sidecar container in the same way as the Cloud SQL Proxy.
Spanner instances are configured to have a specified number of processing units. This computed capacity determines the amount of data throughput, queries per second (QPS), and storage limits of your instance. This was previously the number of nodes in the cluster, with one node being equivalent to 1,000 processing units, and one node being the smallest configuration.
This meant there was no cheap way of using Spanner. Now it is possible to specify a minimum of 100 processing units, which is equivalent to 0.1 nodes. This is a much more cost-effective way of using Spanner for small applications, development, and testing.
When creating a Google Cloud Spanner instance, you’ll often observe a notably quick provisioning time compared to Cloud SQL. This expedited setup stems from Spanner’s unique architecture, designed for horizontal scaling across a global and distributed system. Instead of allocating traditional “instance-specific” resources, as many relational databases do, Spanner simply reserves capacity within its pre-existing, distributed infrastructure. On the other hand, Cloud SQL requires time-intensive provisioning because it establishes traditional database instances with designated resources (CPU, memory, storage) based on the user’s configuration. With Spanner, you’re seamlessly integrating into a vast, already-established system, while with Cloud SQL, you’re carving out a more personalized, dedicated space.