Cloud Spanner is another Relational Database management service provided by GCP. This is different from Cloud SQL in many aspects, such as:

• It is a Google Proprietary technology (no open source)
• Costlier
• Stronger ACID values (ACID++)
• More reliable
• More relational
• More transaction specific
• Fully managed

You ought to pick Spanner over Cloud SQL in use cases involving the following:

• Data sizes exceeding 10 TB
• Heavy usage, with QPS (queries per second) exceeding 5K
• Users in multiple regions (spanner has replication across regions, Cloud SQL is regional)

The technology behind Cloud Spanner is cutting edge. Unlike traditional RDBMS, here rows with the same primary key (which are the most related ones in most cases of transactional applications) are brought together and converted into a new entity called a split. Each split is replicated multiple times over failure independent zones, which mostly removes the probability of data loss and also achieves geo-redundancy by default. This also reduces latency regardless of the regions. Here is an example of such a representation. All of this does make Cloud Spanner a costlier option compared to Cloud SQL but we are spared from manual scaling and managing the instance so users have to make the trade-off:

Concept of splits can be understood more accurately with the following figure:

As we can see in the table, a unique customer ID is provided to each user, which acts as their primary key. User rows are arranged based on their primary key, which grants Cloud Spanner faster access to all of the fields of a single user. This also creates a parent-child relationship between rows. Each row with one field holding the primary key value is considered the parent and the other rows with the same primary key are arranged below it, which are called Child rows. The combination of parent and child rows is what exactly a split is.

Each query is attempted using a primary key, which makes the atomicity as good as absolute. These primary key based arranged rows create a split. In our case, Tony Stark or Jerry Renner are individual splits in the same schema. Coming to the next figure, each of these splits are stored individually in Cloud Storage buckets with optimum configuration (scalable SSDs forever) and is also replicated a minimum of two times.

Google assures us that each replica is stored beyond regional point of failures. So if your original split is in US, the replica may reside in Mumbai (for multi-regional nodes, more on that later). And they also assure us that there are enough replicas to avoid potential data loss. And all of this is managed by Google itself. Although generally the split shown in the figure is ideal, practically, parent-child combinations with identical primary keys (sequential mostly) end up in the same split and while making write requests and multiple writes may end up on the machine handling the same split while other zones or nodes remain idle.

The preceding figure gives a conceptual representation of divided writes, let's look at them with the same data example.

As shown in the preceding diagram and table, to avoid hotspotting on a single node or server, it is advisable to hash our primary keys in a way that they turn into different splits. This way Cloud Spanner can have proper splits due to which the operational load of write cycles can be divided equally.

Apart from this, Spanner also saves logs of each query and its outcome with precise timestamps. This is one of the aspects of Cloud Spanner that helps it in increasing the ACID values. In case of Atomicity, sometimes we do know that serialized queries are atomic, but we are not sure about their exact order of execution. In case of Cloud spanner, splits keep the queries atomic, while timestamp logs assure that they were performed in the correct order. All of this needs heavy processing and scheduling. And so, Cloud Spanner queries (or calls as they name them) are divided into three categories:

• Locking Read-Write transactions: These are the slowest ones. But this is the only mode that supports writing of data, so in many cases its use is inevitable. But it does not become much bothersome since in the case of OLTP, writing of data is not as latency sensitive as reading (you would gladly spend a couple more seconds in setting up your payment details for the first time, speed would be demanded while making payments where we only read credentials. Even in the case of modifying the remaining balance after a transaction, people normally wait without complaint for a few more seconds).
• Read-only transactions: These transactions are consistent for several reads, but do not allow to commit writes. Rather they do not commit at all! They are faster than R/W transactions and we can also read stale data (data from a timestamp in the past).
• Single Read Calls: While Google docs only list two types and consider this one as a special case, it is safe to list single read calls as the fastest reads among three. These calls are not treated as transactions. They only apply to single rows or splits (single or hotspotted primary key holding rows) and reads are performed in a single process. This does not count as transaction in Google's backend, so obviously no commits are made and here too, we can demand a stale read.

Now, let's play with Cloud Spanner a bit.