DEREK DOWNEY: Hi.
I'm Derek Downey, a developer advocate for Google Cloud.
I am currently working on developing a banking
application that leverages Cloud Spanner, the highly-scalable,
managed relational database from Google Cloud.
[MUSIC PLAYING]
In the previous video, I set up a regional Spanner instance
with a small amount of compute capacity
for developing my banking application.
I also created a customers database on the instance.
And all the tables related to my app will live in this database.
Now, my company might have other internal-only data completely
unrelated to my banking app.
That data could be placed in a separate database,
because Spanner instances can have multiple databases.
Databases are a way to organize related tables together
and to provide additional access control to the data stored
on the instance.
For example, my banking app should definitely not
have access to the internal database.
Besides access control, each database
can be configured with different options that
affect the performance, recovery,
and security of your database.
These options control the optimizer version,
version retention period, and database encryption.
The first database option is the optimizer version.
The optimizer's job is to create an execution plan that
is an efficient way to retrieve data from Spanner based
on the given SQL query.
It has a direct impact on performance of requests
issued to your database.
Over time, the query optimizer will
change to improve the accuracy of the estimates required
to create this execution plan.
When Spanner releases a new optimizer version,
the default behavior is for databases
to use the new version 30 days after release.
Optimizer versions can change the performance
of your query workload.
So it's important to compare query performance
of the new version with the older version.
You can pin the optimizer version
a database uses to a specific version
by altering the database.
Altering the database optimizer version to null
resets to the default behavior of updating
30 days after the release of a new version.
You can also change the optimizer version
for individual queries by providing the optimizer version
query hunt.
This is useful to validate queries
where stable performance is critical without changing
the optimizer version for the entire database.
Another important database option
is the version retention period, which
affects the ability to perform a point in time recovery.
By default, Spanner will maintain
all versions of the data and schema for one hour.
In my banking application, I want
to protect against accidental data loss.
With Spanner's default retention,
I have an hour to copy the data as it existed
before an accidental change and then
load it back into the database.
During normal business operations,
this hour might be enough.
But what about during off hours or the weekend?
I might not be able to respond in time to avoid data loss.
So I want to be sure to size my version retention
period to give my team enough time to recover outside
of normal hours.
One way to do this would be to set the version retention
period according to my backup frequency.
For instance, if I take a backup of my database once a day, then
I will want to set my version retention period to one day.
The last option I will cover is how encryption is
handled for Spanner databases.
All data in Spanner is encrypted at rest.
By default, this encryption is handled for you
by Google Cloud.
However, if you have specific compliance
or regulatory requirements on the keys encrypting the data,
Spanner offers the ability to deploy your own encryption
keys.
These are called Customer Managed Encryption Keys,
and are managed through Google Cloud KMS.
It is possible to have some databases configured
with customer encryption keys, while other databases
on the same instance use Google Cloud to manage encryption.
Setting up and managing these custom
encryption keys is beyond the scope of this video.
But there are some important pieces of information
when using custom encryption keys.
First, a database must be created
with the custom encryption key.
Custom encryption keys cannot be enabled on an existing
database.
Second, for backups, the primary version
of the encryption key at the time of backup creation
is used to encrypt backups.
Finally, encryption keys must be available to decrypt
the database and backups.
If a key is deleted and can't be recovered,
any Spanner database or backup encrypted with that key
is unrecoverable.
For now, I will be using the default encryption managed
by Google Cloud for my banking application.
Cloud Spanner offers the ability to organize related data
into multiple databases on your Spanner instance.
This provides some additional control
over who has access to the data stored there.
In this video, I went over some other options
that give you more control over the performance, recovery,
and security of your Spanner database.
In our next video, I will go into more detail
about the Spanner schema, including
data types, data organization, and schema management.
In the meantime, please let us know in the comments
if you have any questions around database specific options
in Spanner.
[MUSIC PLAYING]