Cloud Spanner…
Decouples compute resources from data storage
Cloud Spanner is a fully managed, mission-critical, relational database service that offers transactional consistency at global scale, automatic, synchronous replication for high availability, and support for two SQL dialects: Google SQL and PostgreSQL.
Architecture of Cloud Spanner
Spanner is a worldwide database system with a minimum of three shards per area. Each shard will be in a different zone. A shard is known as a Split in Spanner. If you provision a single Node Spanner cluster, you will receive two more Nodes in a separate zone that are invisible to you.
We’ll have more Splits (shards) in the storage layer based on the partitions. Each shard will be replicated across all Zones. For example, if you have S1 on Zone A, it will be replicated to Zones B and C. The replication method is based on the leader-follower model. The Spanner APIs are aware of the Leaders if you write something on this Split. As a result, the write is sent directly to the zone with the Leader Split. Each Split has its own zone for leaders.
Instances in Cloud Spanner
Instance creation includes two important choices: the instance configuration and the compute capacity. These choices determine the location and amount of the instance’s serving and storage resources.Once an instance is created, you can list, edit, or delete it. Spanner is a fully managed database service which oversees its own underlying tasks and resources, including monitoring and restarting processes when necessary with zero downtime. As there is no need to manually stop or restart a given instance, Spanner does not offer a way to do so.
Instance Configurations
When you create an instance, you must configure it as either regional (that is, all the resources are contained within a single Google Cloud region) or multi-region (that is, the resources span more than one region). You make this choice by selecting an instance configuration, which determines where your data is stored for that instance.
Compute capacity defines amount of server and storage resources that are available to the databases in an instance. When you create an instance, you specify its compute capacity as a number of processing units or as a number of nodes, with 1000 processing units being equal to 1 node.
How to connect to Cloud Spanner
A Looker Studio data source can connect to Cloud Spanner databases using Google Standard SQL query syntax.
To connect
- Sign in to Looker Studio.
- In the top left, click
- then select Data Source.
- Select the Cloud Spanner connector.
- If asked, authorize Looker Studio to access your data.
- On the left, set up the connection to your database. You’ll need to provide:
Project ID
Instance ID (see the Notes below to find out how to list your instance configurations).
Database ID
7. In the text box, enter your SQL query.
8. In the upper right, click CONNECT.
Use Cases of Cloud Spanner
Financial Services:Communications among banks, fintech and regulatory bodies must run flawlessly around the clock. In addition, applications such as payment gateways and online banking are tasked with handling hundreds of millions of transactions with perfect consistency, all while putting those transactions through sophisticated anti-fraud and settlement processes. In the past, legacy databases had to be painstakingly rearchitected to manage this constant flood of data, and bespoke solutions were fragile. Google Cloud Spanner handles the storm with ease.
E-commerce:E-commerce has been ramping up in complexity for years, and the COVID-19 pandemic has only accelerated this evolutionary process. The task of matching orders to inventory is complicated by just-in-time fulfillment and dynamic pricing. Every stockout sends your sale and your customer to the competition. Additionally, you have to plan for seasonal spikes in business. In the past, the default solution was to overprovision hardware in anticipation of seasonal demand. This very expensive approach for handling spikes in usage is now obsolete. Google Cloud Spanner offers elastic scaling to meet surges in demand, and you pay for that increased scale for only as long as you need it. When the demand returns to normal, so does your billing.