Hello everyone! This is Jon from Beyond GTA Inc, and today we will learn about another database which is Cloud Spanner, a global RDB service provided by Google Cloud.
Overview and features of Cloud Spanner
Cloud Spanner is a powerful, fully managed relational database service.
It provides transactional consistency, schema, SQL (ANSI 2011 and extensions), high availability, and automatic synchronous replication for disaster recovery (DR) at a global scale.
It is an enterprise-grade, globally distributed, highly consistent database service built for the cloud with the benefits of a relational database structure and scales horizontally to thousands of non-relational nodes.
Use Case
The following are some of the case scenarios where Cloud Spanner is used:
You have relational data that requires strong consistency.
You have data replication that requires high availability.
Multi-region deployment of databases is required.
You need high scalability (you can start small and scale quickly as needed, exceeding the scale limitations of traditional relational OLTP systems).
Cloud Spanner Architecture
Cloud Spanner is a global database that offers two types of configurations: regional and multi-regional.
To logically partition the data and facilitate proper replication and sharing of data, Cloud Spanner uses instances and databases.
Instances and Databases
An instance refers to the allocation of resources used by Cloud Spanner's database, created in that instance. The creation of an instance consists of two important choices: instance configuration and number of nodes. The instance configuration defines the geographic placement and replication of the database within that instance.
A database is a collection of tables within an instance. A Cloud Spanner database holds tables and indexes that allow data to be read and written. An instance can have multiple databases.
■Regional instances
A regional instance spans a single Google Cloud region.
In a regional instance configuration, Cloud Spanner maintains three read/write replicas, each located in a different Google Cloud zone in that region.
Each read/write replica contains a complete copy of the operational database that can handle read/write and read-only requests. Since Cloud Spanner uses replicas in different zones, the database can continue to be used in the event of a single zone failure.
■Multi-regional instances
In a multi-region configuration, the database data can be replicated not only to multiple zones, as defined in the instance configuration, but also to multiple zones across multiple regions.
These additional replicas can be used to read data with low latency from multiple locations near or within the regions in the configuration.
At the cost of a slight increase in write latency, multi-region instances can be very useful if you have applications that need to read data from multiple geographic locations, as they allow applications to achieve faster reads from more locations.
Each multi-region configuration contains two regions designated as read/write regions, and each region contains two read/write replicas. One of these read/write regions is designated as the default reader region. （In a multi-region configuration, one of these read/write regions is designated as the default reader region, meaning that it contains the reader replica of the database.)
In a multi-region configuration, the quorum (read/write) replicas are distributed across multiple regions, and because of the trade-offs involved, these replicas may communicate with each other and vote on writes, which can cause additional network latency. (Cloud Spanner needs to persist commits in at least two different regions, which increases commit latency.)
■High-level architecture
To put it bluntly, Cloud Spanner's functionality is primarily supported by the API server.
You communicate with Cloud Spanner using sessions in the execution environment of the Cloud Spanner client library. (Each session is associated with a single database, and only one transaction can be executed at a time.)
Sessions are assigned to API servers so that they can maintain transaction state.
API servers are not deployed at the zone or region level, but can be shared across regions and can include multi-regions.
Based on the API request, the API server will determine which node server to communicate with in order to complete the request. A node server is a node assigned to an instance that performs most of the work. The node server handles read and write/commit transaction requests, but does not store data. Data is stored in Google's underlying distributed file system, which is provided by other storage nodes.
Conclusion
The impression of using Cloud Spanner is that if a global company (a company with data in different countries) that needs consistent data processing with low network latency, Cloud Spanner may be worth trying.
This article is originally written by Yuya Ohara who works in Sales Department of our HQ in Japan.
Comments