ROBERT KUBIS: Have you ever set up or managed a distributed
database and are tired of the operational headache?
Or, are you considering moving to one for scalability and high
availability reasons?
Oftentimes, you have to choose between scalability
and consistency.
But also, ease of setup and manageability
are important factors to consider.
Hi, I'm Robert Kubis.
And in this video series, we talk
about Google Cloud Spanner, a fully managed relational
database service.
So do you want to know how to provision
and scale a mission critical database in seconds
without having to worry about consistency or maintenance
windows?
Stay tuned to find out.
[MUSIC PLAYING]
When you hear about Cloud Spanner,
many things feel and sound like magic.
A database that is horizontally scalable while offering
strong consistency across zones, regions, or even globally--
how is this possible?
Before we look into some of the details and technologies
how Cloud Spanner works, let us get your own instance up
and running first.
In the Google Cloud Console, search for Spanner.
Click on Create Instance, and you'll
find all you need to set up your instance in one screen.
You just name the instance.
Select the configuration and how many nodes you want.
Done.
That was easy, right?
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.
On top, new nodes and data are replicated
across multiple zones, or even regions,
for higher availability.
When choosing a configuration, you
have the option between a regional instance
in a particular location or a multi-region instance.
Let's drill down a bit further there.
In a regional configuration, your instance, compute,
and storage gets distributed and replicated
across three zones within one region--
for instance, your rest or your essential one--
making sure your data stays available and consistent
across hardware maintenance, software patches,
or even failure of an entire zone.
But what if you need higher availability
guarantees and a better read performance
from different places?
In that case, you can choose one of
our multi-regional configurations, which
distributes your instance to up to four regions
across the globe.
This allows for an entire region to become available,
while your database still works as normal from all
the other regions.
Having your data available in more than one region also
enables faster reads from those regions.
And the best of all?
You don't have to worry about setting up your own replication
or failure instances.
All this is fully managed for you in one setting.
Now, what about nodes?
For each node you request for your instance,
you get compute resources in all zones and regions,
depending on your selected configuration.
There's no need for difficult planning, and forecasting,
and how many resources to provision upfront.
You can just change the number of instance nodes any time
you need more or fewer.
You just click on Edit Instance, change the number of nodes,
and done.
Really easy.
And if you like your keyboard more than your pointing device,
you can do all this from the command line
as well, or with our client libraries
that are available in many, many languages.
Your instance is now up and running.
Actually, it has been ready and waiting for us
since we clicked that little Create button.
So let's go ahead and create a database and schema.
It's recommended to do both at the same time.
Schemas in Cloud Spanner are just
like any other relational database.
You have tables and columns that are strongly typed.
And if you need to add a table, or index,
or remove a column in the future,
you can just do so without any downtime incurred.
Cloud spanner runs schema changes
in a long-running transaction.
But keep in mind, depending on individual statements
that you execute for schema changes,
they can range from minutes for adding
a column to hours for backfilling
an index on a large database.
Now that your database is created,
you can use our client libraries to write and read data.
Cloud Spanner also speaks SQL, which
lets you reuse and test your existing
skills of working with traditional relational
databases.
The next step is to look into loading some data
and how to do this efficiently.
Unfortunately, we are out of time in this episode,
and we will keep that for the next one.
So if you want to learn more about Cloud Spanner
best practices and inner workings,
follow this featured series and check out
the links in the description.
In the next episode of "Things-I-Learned about Cloud
Spanner," we will look at how to pick the right primary keys
to enable fast and efficient writes and reads.
And remember, you don't need to sacrifice consistency
for scalability.
[MUSIC PLAYING]