SPEAKER: To give you a picture of how amazing Spanner is,
let's start at the beginning, just creating the database.
Those of you who've actually tried
to deploy a multi-region database that's
highly scalable, highly reliable and highly reliant
know that there's like a zillion steps.
You've got to configure machines,
you've got to set up replication,
you've got to worry about failover, you've got sharding.
What happens if I have network issues?
And then there's the operational side
of just keeping the thing running,
having to have full staffs of people who do nothing but take
care of machinery.
With Cloud Spanner, we turn that into one machine.
Robert's going to bring up the dialogue to do that.
He names the instance.
He chooses whether he wants it to be
a single or a multi-regional database,
and then he says how many nodes.
And in this case he picks 42, because that's always
the right answer.
So that's it.
We've now created a multi-regional database
that has amazing capabilities but that's getting started.
Let's look at Spanner in an actual real-world-scale
example.
Imagine you're a ticket seller.
You want to sell tickets to events
worldwide to customers worldwide.
Now obviously it's pretty important
that you sell a ticket once and only once, right?
And it's also pretty important that customers
get a good performance experience
wherever in the world they are buying their tickets.
In this example, we've deployed Cloud Spanner
into three Google regions--
US, Europe and Asia--
all connected by that private network
that Urs told you about.
We're also running workloads that emulate customers
buying billions of tickets.
In this case, we're selling at about half
a million tickets per minute through this system,
all through a system that is maintaining consistent version
snapshots, full ACID support for transactions,
full strong consistency.
That's the power of Spanner as a distributed base, a distributed
database.
Our customers get a low latency experience,
we get good old traditional SQL consistency.
Now, to prove that this really is a database of some size,
let me show you the schema behind this database.
You can see it actually is a SQL database.
There's columns that are joined together.
And if you look at that ticket data table,
it has three billion rows in it.
So while we're doing this, in fact,
we're running all this traffic against a real SQL database.
In fact, we can actually run SQL queries against that database
while it's being hammered with all that traffic.
Here we have a query and if you look
at the bottom part of the WHERE clause,
you see that we're looking for tickets in the US
that are still available as of 10:00 p.m.
and how many seats they have.
So these are our top five events with unsold tickets.
Now what's important here is what you don't see.
What's remarkable is how unremarkable this SQL looks.
If you've deployed a sharding system,
your SQL is a mess because you're
trying to have to do joins across multiple shards
of your database.
In fact, it's probably not even human-writable
SQL when you use those systems.
Spanner takes care of all that.
But real-world applications aren't static,
they change over time.
What happens when your needs change?
Well, first of all, Spanner lets you
make transactionally consistent schema updates
with no downtime, which is critically important when
you're running systems that your business depends on.
And what happens if you get a wonderful success
and your needs grow?
Well, with the traditional SQL database,
you better put a P.O. in for a brand-new server.
You better figure out how to reconfigure the new server,
you better figure out how to migrate the data,
you better figure out how to do cutover.
Or if I'm doing scale out, well, now I've
got to add a whole new complex middleware
layer that's incredibly difficult to maintain.
And even that takes time and adds operational risk.
In Cloud Spanner, Robert's going to go back to the console
and show you how we add capacity to a Spanner database.
We simply go from 70 nodes to 99 nodes.
That's it, we've scaled out.
That's the power of a horizontally scalable SQL
database.
[APPLAUSE]
And of course, since we use Spanner so much internally,
we made sure it handles large database.
Robert's going to switch over to the monitoring console here,
and what I want you to look at is that graph on the bottom
left.
We've been running this whole demo
against an 80-terabyte database.
And if you look at the top right graph,
when we loaded the data in, we loaded the data
at an average of 800 megabytes per second.
And we peaked at about a gig per second of loading data.
That's amazing, that's crazy fast.
So that's Cloud Spanner.
You create a highly reliable performant, fully managed
multi-region database in seconds.
Cloud Spanner is SQL.
You get interoperability in the power of SQL queries.
You get ACID transactions.
Plus, you get advanced features like on the fly schema changes.
Cloud Spanner's fully managed.
We never had to worry about setting up replication,
sharding, failover.
The system actually even tunes itself automatically over time.
So as you use it, it learns your query patterns
and it optimizes its own performance characteristics.
And Cloud Spanner is built for scale.
We've been running our largest production systems
on this for years.
So with that, I'll turn it back over
to Urs for a little bit more of the keynote.
Thanks.