First Steps with Google Cloud Spanner
Setting up and managing a distributed database for better scalability and high availability is difficult and can cause numerous operational headaches. Often you have to choose between scalability and consistency, but ease of set up and manageability are also important factors to consider. Google Cloud Spanner combines the scalability of a NoSQL database with the qualities of traditional relational SQL databases, including schemas, ACID (atomicity, consistency, isolation, durability), consistency across rows and tables, and ad hoc queries.
This post shows you how to get started with Google Cloud Spanner.
Creating an Instance
In the Google Cloud Console search for Spanner, click Create Instance and you’ll find everything you need to set up your instance in one screen.
You just name the instance, select a configuration, and specify how many nodes you want. Done! Within in seconds you’ll have your own instance ready to create a database and load data.
But wait! What just happened? Let’s take a moment here and talk about which configuration to choose and how many nodes to select.
In Cloud Spanner compute nodes and storage are separated to enable scaling each independently. In addition, your nodes and data are replicated across multiple zones or even regions for high availability.
When choosing a configuration you have the option of selecting a regional instance in a particular location or a multi-region instance. In a regional configuration your instance’s compute and storage gets distributed and replicated across three zones within one region, for instance ‘europe-west1’ or ‘us-central1’, ensuring your data stays available and consistent across hardware maintenance, software patches, or even failure of an entire zone. If you need higher availability guarantees and better read performance from different places you can choose one of the multi-region configurations, which distribute your instance to up to four regions across the globe. With this configuration, even if an entire region to become unavailable your database will still work as normal from all other regions. Having your data available in more than one region also enables faster reads from those regions.
And the best part is that you don’t have to worry about setting up your own replication or failover instances; it is all fully managed for you with this one setting.
Scaling an Instance
For each node you request for your instance you get compute resources in all zones and regions depending on your selected configuration. There is no need for difficult planning and forecasting on how many resources to provision upfront. You can just change the number of instance nodes any time you need more or fewer.
And if you like your keyboard more than your pointing device, you can do all this from the command line or with the Cloud Spanner client libraries, which are available in many languages.
Creating a Database and Schema
Now that your instance is up and running, let’s go ahead and create a database and schema. It’s a good idea to do both at the same time. Schemas in Cloud Spanner are just like those in any other relational database — you have tables with columns that are strongly typed. If you need to add a table or index or remove a column in the future you can do so without any downtime incurred. Cloud Spanner runs your schema change in a long running transaction. But keep in mind, depending on the individual statements you execute, schema changes can range from minutes for adding a new column to hours for backfilling an index on a large database.
Reading and Writing Data
Once your database is created you can use the client libraries to write and read data. Cloud Spanner speaks SQL, which lets you use your existing skills and knowledge of traditional relational databases. And if you need a quick way to run queries or to inspect, update, or delete certain records you can do so directly from the Cloud Console.
Next Steps
Check out the code samples here. To learn more about Google Cloud Spanner stay tuned for the next article, which will discuss choosing the right primary keys for fast and scalable reads and writes. And checkout our docs and Getting Started guides.
