Importance of Natural Resources

What’s New with Cloud SQL (Cloud Next ’19)


[MUSIC PLAYING] DAN MCCLARY: This year
in Cloud SQL we’ve really focused on three large areas– overall performance and scale–
make all of our databases faster, make them scale more
easily, make as much of it one touch as possible; overall
reliability and availability, because if your database isn’t
available, it isn’t reliable, what good is it? And then really
full integration, trying to integrate it more
deeply within GCP itself, and then also with
the things out in the ecosystems of MySQL and
Postgres that you care about, and again, things like
SQL Server now as well. And we’re proud of every single
thing we’ve done this year. But I think a few that
really warrant discussion are things like Postgres going GA. 9.6 is GA. And again, 11 is in beta. Our private IP work. And then our regional expansion
we’ll talk a little bit about as well. So lots and lots
of stuff this year. Lots and lots of stuff. Lots of new regions. One of the things
people may have missed is many, many more flags. We have for a long time had
a pretty restrictive policy on what flags we
allowed administrators to set for the
database instances. And ultimately, we’ve kind
of decided that in many cases you know best. You know what it is
you’re trying to do. And so if there was a
flag in MySQL or Postgres you were looking for, and you
couldn’t find it, check again. Both in our documentation
and in our console UI, you’ll find most of
the flags that you’re looking for for Postgres
and MySQL are now there. We’ve upgraded our proxy. We’ve added pushy IS
supports for JSON C. My SQL external master
has been a really great way for organizations to
start to migrate their MySQL workloads into a managed
system with Cloud SQL. Rotating SSL certificates. Real, real interesting
move on the security side. And then connections
from Cloud Functions, which I think over
time is going to grow into a richer kind of external
and trigger system as well. So again, highlight:
Postgres GA. We’re seeing really,
really great adoption in the Postgres side
of the offering. I think those of you who know
about the growth of Postgres over the last several
years in the community understand that for certain
enterprise functions it really is becoming the open
source database of choice. It’s part of the
reason we’re going to have Simon join us to talk
through some of the things we might want to know
as we move into 11. But with Postgres going GA, that
means we now have SLA coverage. And it’s going to be a major
focus for us in the year to come as well. High availability. Again, if your
database isn’t there, It’s not really worth it. So high availability has
been a big focus for us on both the Postgres and
MySQL sides of the house. And it’s worth breaking
these out a little bit, because we’re doing them
a little bit differently. Now on the MySQL
side of the house, you can add high availability
with just a single click. And what you’re getting
is bin log replications. You’re getting
semi-synchronous replication, and we’re monitoring replication
lag as our failover signal. Now that means that there’s
no app level difference for highly available stuff. It’s the same as a
single interface. But you do have the
option to use it. And that secondary replica is
a little bit of a read replica as well. But you’re dealing with the
notion of replication lag as well. We’re doing things a
little bit differently on the Postgres side. And this is actually going to be
the strategy more broadly going forward for our high
availability for SQL Server, for Postgres and
maybe we’ll eventually bring it back on
MySQL world as well, which is actually to build on
replicated persistent disks. Now this is a truly
synchronous replication. And so we’re actually
replicating the block device underneath the instance. And to be honest,
this is a thing we’re really only able
to do because of Google’s overall network capacity. It’s very, very demanding
to replicate a whole block device synchronously. And what this means,
though, is that there’s no replication lag. And it changes our failover
metric a little bit. So in this case, if we get
60 seconds with no heartbeat, we know we need to failover. Now you can’t use that
instance as a read replica. But you can set up regular
read replicas to use otherwise. And you can continue
to serve data from those from a healthy
zone, even if that primary has gone down and we’re in the
process of failing over. And then private IP,
I think, is actually a big deal for the
security [INAUDIBLE] and for those who are
latency sensitive as well private IP is now available
throughout the Cloud Sequel line. And this is going
to allow you to peer your VPC with the Google VPC
in which our instance lives. Now what does that mean for you? Well, that means lower
latency, for one. It also means that all
traffic is encrypted. You can apply TLS to that
as well if you want to. But it’s going to be
encrypted and never exposed to the public internet. And that is going
to be a major driver for certain organizations that
are network security sensitive. Wrong green button. And then regional expansion. I think this has been
a highlight for GCP for the last three
years running now, is just how rapidly we’re trying
to expand across the globe. And we’re now in 58 zones. I’m not sure exactly how
many regions that is. It’s many regions, each
with at least three zones. And this is really giving
you the opportunity to locate your databases
closest to where you need to run your
application, closest to where you need
to do business. And again, this
allows us the ability to have our replication exist
in any one of the regions with, again, good failure
domains across the zones. And now let’s get on to the
next part of our discussion. We’re going to dig more into the
meat of some of the offerings themselves. We’re going to talk
about PostgreSQL 11, and a lot of things
you should know. If you’ve only been running
9.6 or maybe running 10, there are a lot of
improvements in 11 that are really
interesting to talk about. And we’re really, really lucky
to have Simon Riggs with us. Simon, if you want to come up. Simon is the founder
and CEO of 2ndQuadrant. 2ndQuadrant provides a wide
variety of Postgres services in over– what– 20 countries? Is that right? And collectively they have
over 200 personal years of Postgres experience. Now importantly, Simon is not
just the CEO of 2ndQuadrant. He’s also an active developer
and committer on Postgres. And he’s helped bring things
like PITR to the community and partitioning
the replication. So we’re going to
get the opportunity not only to see Postgres
work in the field and talk about
that, but also then sort of the
committer’s perspective on where the database is going. So please welcome Simon. [APPLAUSE] Simon, thank you for coming. SIMON RIGGS: All right. No problem. DAN MCCLARY: This is going
to be a little awkward. SIMON RIGGS: Yeah. Don’t worry. DAN MCCLARY: All right. So let’s start to talk
first about parallelisms. I think one of the
things I notice in 11 is there’s been a lot of
enhancements to parallelism. We see it in parallel query. We see it in
parallel index build. So one thing I wonder
about is, given that scan types and joint types
are now increasingly parallel, what are some things
that users should know when they think about
how parallelism is going to apply in their database? SIMON RIGGS: OK. Well, I think in
9.6 we introduced the basics of parallelism. But we didn’t
really roll that out to everything that
could be parallelized. Whereas by the time
we get to Postgres 11, the journey’s almost done. If you look at what
we’ve done in Postgres 12 release cycle,
mostly bug fixing. And I’m actually very happy that
we got the main join types done in Postgres 10 and 11. So for example, initially
we did hash joins. But they didn’t use
a single hash table, though they had a
separate hash table per– DAN MCCLARY: [INAUDIBLE] SIMON RIGGS: Yeah,
which was very wasteful. So really we’re at
the stage of hitting the secondary and tertiary
issues with parallelism. So it’s almost done. We’re very happy with it. DAN MCCLARY: And so if
users haven’t really thought about how parallelism–
how to take advantage of parallel query, are there
things that they should think about in terms of
setting up their schema, the way they think about
table architecture, that will help
increase their ability to leverage parallelism? SIMON RIGGS: Yes. I mean, it’s possible to get
large parallel databases that exist out there with
different databases. But with Postgres
what we’ve focused on is small parallelism. So intranode parallelism. So really we’re
looking for queries that can be somewhere between
two and four times faster using this intranode
parallelism. So really a lot
of important areas occur in applications, where
we’ve got certain queries that are a bit slower
than they should be, but they’re not running
for necessarily hours. They could be like things
that run for, say, a minute. And if we can get that down
to 10 seconds or two seconds, then it’s goal achieved. So we’re not really
talking about the same world-encompassing
parallelism that you get from
some other products. But making simple changes to
the response time of real world queries. DAN MCCLARY: Yeah. It seems that we would
look to see that maybe in operational
workloads that are dependent on real low latency
or operational reporting and things like that? SIMON RIGGS: Yes. I think what we’re
seeing with Postgres is that the old idea
of an OLTP system where all the transactions are short
isn’t really what we see now. There’s a whole mixed
workload where you get OLTP, but also complex analytical
queries happening immediately. For example, asking
the question, where’s your
nearest coffee shop? Or what’s the best hotel
for this particular customer to stay in? They need to be
quick, but they’re not short in terms of the analytical
power required to answer them. And those are the things
that we’re targeting now. DAN MCCLARY: I suppose
as the modern OLTP database becomes more
analytically oriented, this actually matters. This notion of going from
a minute to 10 seconds could be huge. So another thing
that’s interesting is parallelism in index builds. And I know people
in the MySQL world would be familiar with
things like parallel apply. SIMON RIGGS: Yes. DAN MCCLARY: Can
you say a little bit about how parallelism
for background work is evolving in Postgres? SIMON RIGGS: So in terms of
maintenance functions, I mean, we’ve got parallel vacuum. We’ve got parallel index build,
which the main ones, really. We have moved away
from the idea of trying to do maintenance on indexes. So just rebuilding the
index is a practical task. And because we can
do that concurrently, it’s fairly simple
to build a new index rather than try to
maintain the other one. There aren’t a whole
load of other operations that you’d need to
do in the background. But one thing we have done
is parallelized Create Table as Select, which is quite
important for building summary tables and such like, which
is an important application technique. So that’s really one of the key
things, I think, was the CTAS. DAN MCCLARY: Yeah. CTAS improvement is
actually really huge. I mean, you’re talking
about any kind of summary either pre-offload to warehouse
or for operational reporting. That can have a huge impact. So let’s talk a little
bit about partitioning. So I look at 11, and I think,
this is the partitioning release in a lot of ways. And you were very
early in partitioning. But one of the things that
people may not know about 11 versus previous versions is
that we’re no longer strictly in sort of table
inheritance mode. We’ve got table
attribute partitioning. It’s native. But if you’re
coming from Postgres and you’ve thought
about, oh, well. You know, I read Stack Overflow. And I saw these
inherited tables. It’s different now. And so what should
implementers think about either as they’re moving from
9.6 upwards or 10 upwards, or if they’re designing
a schema from scratch and trying to think
about how do I take the best advantage of
the variety of partitioning options? SIMON RIGGS: So yeah. I mean, I was originally
involved in the work on partitioning
back 10 years ago. And frankly, if I’d
done– not to dis myself, but the work that we
did there was crude. And it led to some
shortcomings, really, with the types of application
that we could support. So what we’ve done now
is completely redesign that, implement it from scratch
the way it should be done. And as a result,
we’re able to support things like unique
indexes on partition tables and foreign keys. Obviously very key
for applications. And it’s really made a
big difference to the way that people are able
to use this now. So partitioning isn’t even
done yet, really, in 11. We’ve still got a lot of good
performance features coming in 12 and in 13. So partitioning is a
really big application area for Postgres and maybe
other databases as well. But we see those requirements
coming very strongly from a whole range of
users, because there’s just so much data these days
that people want to log. And partitioning really
makes that effective. DAN MCCLARY: So I
guess just to poke on that a little bit, given the
wide variety of things that are now present in
partitioning, do you think that opens the door
for organizations or users who are looking to move off of
other RTP maps that have had maybe expensive
partitioning packages or something like that? I mean, do you think that
the level of functionality is enough that there’s a
whole new wave of workloads that can come to Progress
with 11’s partitioning? SIMON RIGGS: Yes. I mean, the style of feature
development with Postgres is because we’re releasing
features annually, we will release a feature
and then add things to our over the next couple of years. Maybe five or 10 years
ago you’d wait five years for the next release. And then it would
all come in one rush, except there would still
be stuff broken, right? And then you’d wait another
five years for it to be fixed. So the Postgres way is to
release stuff a lot earlier. What we have with the
initial partitioning is select queries will
be fully optimized. Inserts are optimized into it. It’s not really
until Postgres 11 that updates and deletes are
beginning to be optimized. And we’ve done more work
on that in 12 as well. So the range of
workloads is evolving. So if you want to
do insert only, sort of append only workloads, they
work just fine in Postgres 11. But we’ll be moving
on to a whole range of other applications. Your slides there mentioned
partition wise joins and partition movement. Those two features
are particularly relevant for sharding
style applications built using partitioning, whether
the partitions actually exist on separate nodes. And that’s really a
direction that we’re moving in for the
next couple of pieces is that sharding concept. So not too long away from
having a fully sharded database running on Postgres. DAN MCCLARY: That’s great. I guess you make an interesting
point there around the Postgres release cadence. And I think for people
who are thinking about planning potential
migrations to Postgres, if partitioning is a strong
requirement, this notion that we can begin to
plan our migration now as the features are
set but improving, it maybe can actually reduce
some of the risk profile of that kind of a migration. SIMON RIGGS: Yes, definitely. I think what some
people say is that they won’t move to a release until
it’s been out for six months. Well, obviously with
Postgres coming out annually you don’t really have to wait
as long as you did before. And quite frankly,
the profile of testing has changed dramatically
in software generally, and most specifically
in Postgres. So whereas we used to rely
on the kind of many eyeballs effect for people
reporting queries, the extent of our test
automation is now– I mean, I can’t
put a number on it. But it’s much different
to how it was. And so you have a lot of
trust in the .0 release now, whereas before
people said, well, maybe wait for the .1, .2. But you know, it’s usable,
really, from the word go. So every September now
you should be thinking about upgrading your Postgres. DAN MCCLARY: That’s
really interesting. So let’s talk about
another one of these, hey, maybe I have an expensive
database at home, and I’m interested in
getting away from it. Another huge thing in
11 is stored procedures. And I think the community has
had functions for a long time. But procedures, they play a real
role in ensuring conformance, in reducing network
traffic, a bunch of things. And you guys at 2ndQuadrant
actually did a lot of work on the stored
procedures as well. Can you talk a little
bit about what you think they mean for the community? And I guess same question– if I’m thinking about coming
from a database that is on premises or is maybe
something I’m trying to get off of, but stored procedures
have been a blocker, how is the door open now
in a way that it wasn’t? SIMON RIGGS: I mean,
there’s a small difference between procedures
and functions. I mean, functions are
essentially– well, procedures are– you know. They’re very similar
in many ways. But the key
difference that we’ve introduced with
stored procedures is the ability to
run transactions inside the procedure. And that is a really
pivotal difference. It’s important for migration
from other databases. But it allows you to do a whole
range of things you really weren’t able to do before. So batch style query processing. And we’re also moving towards
autonomous transactions within procedures, perhaps
in the next release. But the style of programming
changes completely, because when you had a
function that would only exist within one
transaction, you’re now having a procedure that
can exist perhaps generating thousands of transactions
as it executes completely different style of programming. And it really moves a
lot of the business logic through to the server now. Because whereas
before you had to ask for one transaction and
then another transaction, the procedure can
just do it all. It’s like, come back
when you’ve finished now. And that means that the
network traffic that you’re reducing between the
application and the database is really considerable now. So we get the full benefit
of offloading things to the database. Obviously not every single
piece of your application should live in the database. OK? I think some people
tried to persuade people that was a good idea. And it’s not. OK? But there are some
things that make sense to be close to the data. OK. And for those, it’s ideal. DAN MCCLARY: It’s interesting
that you mentioned the notion of having
multiple transactions within the procedure. I recall working in financial
services and other places that the notion of
straight through processing can be a real impediment
for certain organizations that need to make sure that
when this row is touched, all of these other
roles are updated. And so this really
opens the door to that. Do you find that
you’re seeing growth in the sort of regulated
industries on Postgres? SIMON RIGGS: Absolutely. Yeah. I mean, probably half
of our customer base is financial services now. Very widely used across
financial industries. And when I say that, I think
some people think, oh, right. So somewhere in
the back room he’s got like one Postgres
database, and he’s claiming that as usage. Right? No. I’m talking about
card processing is now frontline done on Postgres. So if you buy something on
various cloud providers, you will find that that goes
through Postgres databases. And there’s literally hundreds
of billions of dollars annually processed directly on
Postgres databases supported by us, by the way. DAN MCCLARY: Well,
there’s something interesting within
that too when you start to talk about
global organizations. And I know one of the
areas that 2ndQuadrant’s done a lot of work beyond things
like stored procedures is also in logical replication,
things like BDR. Could you talk for a
moment about how you’re seeing sort of cross
regional replication emerging in the Postgres community and
the kinds of use cases you’re seeing for it? Be it disaster recovery or
split transaction processing, the sorts of things that
really show up there. SIMON RIGGS: Certainly. Yeah, I think there’s various
ways of doing high availability within a single region. But when you go
cross-region, things become a lot more complex. And some of the storage
replication techniques that are possible become
much more problematic. So Postgres has
invested a lot of time, and 2ndQuadrant as well, in what
we call logical replication. And the purpose of
that is to filter out all of the physical
replication stuff so that we’re just
down to the basic data. So that reduces
bandwidth, but it also allows you to do things like
upgrade between release. And it certainly makes
cross-region replication significantly easier. And with something
like BDR, we actually have global geosharding
where you can actually have pools of data in
different continents, and yet all working together. So again, important
technologies, especially in regulated industries. DAN MCCLARY: And
just in case folks don’t know what BDR is–
bi-directional replication. I think you and I know
enough, it’s, like, oh, well. Of course this. So we talked a little bit about
the importance of analytics within the Postgres world. And I mean, in a
lot of ways Postgres is really well-positioned to be
both your analytical workhorse for operational things
and your OLTP database. The other thing that really
stood out to me in 11 is the changes to
analytical SQL. And I think in many ways I
look at PostgreSQL syntax as being in a lot of cases
at the very edge of how we think about the SQL language. So for folks who
have looked at it, Postgres 11 gives
us frame exclusions, which I think are really,
really powerful ways to actually remove things
from the windowing frame, and then also group
frame units, which is– I don’t think any
other database today does group frame windowing. Can you talk a little
bit about each of these and what it means to
the analytical workload? SIMON RIGGS: Sure. So, I think what a
lot of people don’t realize with SQL is that it’s
had window functions in it for some time now. And what a window
function is it allows you to look at data
in an ordered manner. And this is especially
important for time series, where if you’re thinking about
your data as a graph where the points change
over time, then you can write queries that
analyze that data so that you have a sliding frame of data. So for example, if you look
at the current row of data, you can look at the
last five preceding rows and write something like
a moving average, which is obviously a very important
analytical calculation. So this has actually
been in this SQL standard for many years. And Postgres has
had support in that for coming up for 10 years now. But in the latest
release we’ve got these fine-grained
extensions, really, that put the finishing
touches to Postgres’ support. And the ones that you
mentioned there really are just important in
really just getting the last few dregs
of information out of that style of query. And what’s really
surprising, though, is we are finishing
the implementation of these features. And yet many people have
never even heard of them. OK? And so sometimes when
we talk about SQL a kind of boring language that
existed from 30 years ago, people are not really
moving with the fact that it’s actually evolved
very considerably over time. DAN MCCLARY: Yeah. Modern SQL is really something. To think a little
bit about that– to the finer grains
and a frame exclusion, I might have my moving average. But I might want to say, well,
give me the last five values, but remove the duplicates. Right? And that could actually have
a really material change on the average in computing. And again, that sliding
window doesn’t necessarily have to be rows
proceeding anymore. Right? It can now be groups. And so if I’m actually talking
about group by averages, that can be really interesting. All right. So let’s talk a little
bit about data types. I think Postgres already has got
a really rich support for data types, whether it be
array types, structure types, domains. But I think one area
that’s interesting is semi-structured data, because
JSON and JSON/B have become, I think, interesting additions
to Postgres in general. And in particular, I think at
11 we got full text indexing. Or it might have been 10. I’m not 100% certain. So are you seeing more use
of semi-structured data in the Postgres world now that
these features are available? SIMON RIGGS: Very much so. I think people have
bought into the concepts of semi-structured data from
a lot of other databases. But they want to
use those concepts within a normal
database structure. So they want to be able to
mix the concepts together. Relational works,
but up to a point. And then when once
you go sort of past that point where you
hit the complexity wall, semi-structured data
is really useful. So it’s great to be able
to just have a column where you have sort
of data blobs in. And JSON and JSON/B is
just excellent for that. So we have lots of
people using it. So it’s not something
that’s in the back rooms. It’s really one of our
key features these days. The JSON/B data type
compresses the data. So we store it
compressed, but in a way that you can still search on
the compressed data, which obviously is a very
important feature. So the full text support that
we’ve released in Postgres 11 is actually enabling
two things that were in Postgres previously. Obviously, the JSON data type. But the full text
support allowed us to build indexes on data,
but in a very complex way. So we could have things
like a Russian grammar for words in the JSON blobs. And you’ve got things like
a stemmer that will take the front portion of the word. So instead of a word
that ends with -ing, we can just take off the -ing,
and it’ll be the main word that we’re talking about now. And we can just
index that instead. So that the full
support of full text is now available on
top of JSON/B data. So a very important combination. DAN MCCLARY: That’s
really interesting. I think one of the things
that that kind of highlights between thinking about
the analytic functions, thinking about
semi-structured data types, and being able to
actually effectively do complex processing on them, is
that I often think of Postgres as it’s an OLTP system mostly. But the reality of it is it’s
really a multi-model database in a lot of ways. Like, if you need to do things
that are somewhat key value oriented, if you need
to do things that are more sort of Elasticsearch
full text indexing, like, these are all capabilities
available to you. And if you need to bring them
all together in one database, Postgres is really
about the best you can do in the
open source world. SIMON RIGGS: Very much so. I mean, I think that’s really
been the power of Postgres is while many vendors
have been highlighting, I’ve got this great database
as long as you accept this long list of restrictions. OK? And then there’s
another database server that has a different long
list of restrictions. And trying to build
an application that integrates different
servers together works at the prototype stage. And then someone says,
how will I back it up? And simple things like
that become really complex. And what Postgres
has done is said, really there aren’t
any restrictions. You can have all
manner of data types with all manner of index types. And we support OLTP queries,
longer analytical queries. We support graph
queries, for example. Not very well-known. Window queries. And this really gives
you a breadth to Postgres that means that when you’re
building an application, you can be pretty
certain that you will be able to build it on Postgres. Whereas some of the
other platforms, you have to look carefully
at the list of restrictions before you decide
whether to use it or not. And if your restrictions change
after your initial build, you’re in problems. And that’s really the
strength of Postgres has been the confidence that
it gives application builders. Because as I said,
you can be certain that Postgres will run it. DAN MCCLARY: Yeah. It’s actually a great platform
to avoid pre-optimization. Right? You can optimize
when you need to. But if you’re not quite sure,
Postgres will probably at least get you most of the way. All right. So it’s a new release. And you can’t have a new release
of a database without somebody want to talk about
speeds and feeds. So this is not any kind
of an official benchmark. This is just I spent a
little bit of time one afternoon looking
at Postgres 9.6 on Cloud SQL and
Postgres 11 on cloud SQL. And I was just looking
at effectively tpm-C. And I think I see some
interesting things. Right? The theoretical
throughput is up overall. We see improved behaviors. But I know there’s been
a bunch of work that’s gone into the planner, into
the stats collection, things like that. Anything you want to say broadly
about overall performance in 11, or things that users
should be aware of, they should be taking advantage
of, that maybe they didn’t read deeply enough in
the liner notes to know about? SIMON RIGGS: Well, thank you
for asking that question, because the things
I like to highlight is those things that are
kind of buried in the notes. But really I’d like to celebrate
what you see on the screen there, because if you look– I mean, the numbers
there are extraordinary. We’ve gone from
8,000 tpm to 12,500, which is more than a 50%
gain in performance in OLTP. And that’s really
just one workload that has been optimized,
because there’s a whole range of other
workloads that we support. So I mean, that in itself is–
we could talk for five minutes, really, about that. But really to answer your wider
question, what we’ve been doing is not just expanding the
execution speed of queries with things like aggregation
improvements or parallel query, but we’ve also looked at
the statistical information that we keep within
the database. So we now support something
called the create statistics command. And what that allows you
to do is tell the database that multiple columns
are actually linked. For example, there’s a
common example of in the US you have area code and state. Now we all know the area
code and state are related, but the optimizer doesn’t. And it’s only when you
tell it that these two columns are actually related. And the area code for Los
Angeles is not the area– it’s not possible
to have a customer with an area code in Los Angeles
when they live in New Jersey. It just doesn’t happen. OK? And so the optimizer can use
those types of information to really change the
selectivity estimates. And when you get the
selectivity estimates right, you get the right query plan. And most of the reason for
poor performing queries is actually because of
the optimizer’s ability to understand what’s happening. So I don’t want to denigrate
the massive work done on parallel query at all. But we’ve done an equal amount
of work on the optimizer, on statistics. So for example,
in Postgres 10 we introduced for the first time
foreign keys into planning. So previously, foreign keys
were just a constraint. Right? Whereas now the foreign
keys are actually taken into account in the planning. And that means you get much
better plans and faster queries as a result. So those are not
really admin tasks. There’s some pretty cool admin
things out there as well. But really performance across
all of the different workloads has improved really
quite considerably. DAN MCCLARY: That’s awesome. Yeah. I think that the notion of
understanding that we can now actually help improve those
plans in ways we couldn’t before, any of us we’ve
ever run a benchmark know that if you don’t
get a good plan– it’s just like life. It’s just like life. All right. Well, Simon, thank you
so much for joining us. Everybody, give it
up for Simon Riggs. CEO of 2ndQuadrant. [APPLAUSE] Wow. There’s a lot of stuff PG 11 you
guys have got to go check out. It’s really, really cool. So let’s talk just briefly
about the year ahead. And then I’ll hand
it back over to Ori, who’s going to give us
another taste of SQL Server, in case you didn’t see
it on the keynote stage. So in 2019 there’s
a lot of stuff we’re interested in–
new database versions, new databases, for example. Some security features we think
are really important, customer managing encryption keys. This is a broad requirement
for all of Google Cloud. And you’re going to see it
in Cloud SQL very, very soon. Richer auditing. Simon and I talked a little
bit about regulated industry, financial services, health care. We really want to improve
the level of auditability in Cloud SQL so
that we’re yet again further ready for these
kinds of workloads. We’re also going to
spend a lot of time this year focusing
on manageability. If you’ve run Cloud SQL and
you wonder about maintenance events, we know. We know. We’re working on both
deferrals and event controls. And these are
things we’re really going to focus on making at
least first class in the coming year. Point-in-Time recovery
for all of our databases is a huge priority. We already have it
in the MySQL world. You’ll see it in Postgres. And obviously, you’ll
see it in SQL servers. And that’s something you expect. Our overall
manageability UI we’re going to invest a lot of time
into and try and improve that. And we’re also going to start to
begin a journey towards greater federation with the rest
of the GCP platform. One of the areas that
we expect to invest in– this year’s federation
from BigQuery, which is to say if
you have a warehouse stored in Google
BigQuery, you’ll be able to reach
into your Postgres database and query operational
data that may live there. We’re also very interested in
potentially having Postgres reach out to the rest of GCP. We think that’s a
really interesting area that we’re going to
investigate going forward. And with that, I’m going to
go ahead and turn it over to Ori, who’s going to
tell us about SQL Server. ORI KASHI: All right. Thank you very much. Hi, everyone. So I am here today to talk
to you about a product you I’m sure have
never heard of– SQL Server. We’re really excited to
announce that we’ve expanded our portfolio for Cloud SQL. And now we will be offering
managed SQL Server. Currently we’re launching
our closed alpha. Beta will come towards
the end of this year. And that will be open
to all customers. Now a lot of what Dan
was talking about, and why it’s so important to
be part of the Cloud SQL family is really that SQL
Server is going to take advantage of a lot
of the platform goodness that we’re bringing already
to MySQL and Postgres over the coming year,
and leverage the same set of features. So when you talk about– I get the question all the time. What regions is SQL Server
going to be available in? The answer is, everywhere
that Cloud SQL is available, that’s where SQL
Server is available. And the same goes for what are
automated backup stories going to be. Point-in-Time
recovery is coming. Patching story, all that. We are going to have kind
of this unified experience that you can come to expect
as a standard from GCP for admin and services. And SQL Server will
be no exception. And so that’s going to add
hopefully a lot of value, reduce a lot of the overhead
in terms of managing SQL Server and how it interacts
with your apps. Additionally, I want to talk a
little bit about compatibility. So SQL Server– in
most organizations that we’ve run through with
a lot of the customers, they already have kind of
their workflows baked in. They have their favorite tools. They have their third
party analytics services or whatever else they’re kind
of running on top of SQL Server. One of our top goals is
actually to make sure that we are able to preserve
that level of compatibility. So we’re not going to
introduce something where you have to
break your normal flow, retrain a bunch of your folks. We expect you to be able
to continue doing business as usual, just with a managed
service in the background to reduce, again, a lot of
that maintenance and overhead. Just some quick bullets. So SQL Server 2017 is
going to be the version that we’re going out with. As I said, there is kind of this
versioning strategy across all of our managed database
services that we will continue to keep up-to-date with, of
course, the minor revisions. And as the major
versions come out too, we’ll evaluate them and
make them available as well. We’re starting out with
our Alpha Standard Edition. But we will at the
time of Beta and GA have all editions
available to our customers. The VM shapes that
are underlying this are going to be the same
as the rest of Cloud SQL. Again, there’s that
kind of standardization across the Cloud SQL family. And so everything that you see
that customized I think already in Postgres, there’s
custom VM shapes, that’s actually the standard
that we’re going to adopt. The only limitation,
of course, is going to be the different
editions of SQL Server have kind of baked-in
limits on what they can utilize as far as memory
and cores and things like that. And then finally, again, Dan
touched on this a little bit with the comment about
federation with BigQuery. But I think it bears
repeating that integration with Stackdriver,
integration with all the other available
tools and services that kind of proliferate
around the GCP ecosystem is going to be one
of the biggest value adds that we have. And SQL Server is going to
benefit a lot from that. And so if you are already
kind of a customer for any of our other services– using
Compute, using something else– this should be an easy add-on
if you have a stubborn workload that’s remained on prem,
or in a VM, even in GCE that you want to kind of
go to a managed model. That’s something that
will be available to you. I think the slides are
available after the session. So there is a link, if you
are interested in Alpha. To show your interest, sign up. We have a set of
customers selected now. But we’ll be expanding the
Alpha as we get closer to Beta. And we welcome any
interested parties. We’re happy to have
you if there’s space. And with that, everyone’s
favorite thing– a demo. So this is actually running
on SQL Server 2008 R2. It’s going end-of-life,
obviously, later on this year. In just a few short
months actually. Team that we start out with–
.bak as the first supported back and restore file type. Obviously, that’s the
native one for SQL Server. I know the team worked very hard
to make sure that that is first out the gate. And then after that we actually
have an incredibly simple import flow. And it’s very similar to what
you’ve already seen for .SQL and .CSV imports. But I’m just going to go and
select this .bak file that I’ve uploaded previously. There we go. I’ll just name it too. Let’s call this skidb001. I’ll click Import. And while that is
happening, I’ll actually– this usually only
takes a minute– I’ll copy over the IP. I’ve got the configuration
file over here. I’ll paste it. And with any luck it
should still be up. Yup. All set. So now this web app is running
on our managed service. And it was that simple. And that’s actually our
goal for our customers. So we want to make sure that
if you have more complex apps, obviously, it’s going to be
more than this [INAUDIBLE] process I just showed you. But we want to provide you
with the tooling, not just the simple flows, but
also through third party relationships,
through other tool sets that we’ll make available. You, of course, heard about
the Illumina acquisition that happened earlier this year– or just earlier this month. And we’re really doubling
down on making sure that the migration onto GCP,
onto our managed services, is smooth and painless. One other thing I wanted to call
out before we get to the Q&A is actually two things. One is a quick shout out to
our Managed AD service that is also launching right now. And for GCE as a
whole, we kind of have an entire Windows
ecosystem offering now, which it’s a much more complete
story than what was, of course, previously available. And so whether you’re trying
to run Windows Server on GCE, whether you’re looking
to use our Managed AD service and Managed
SQL Server, now you don’t have to kind of
bit-wise or piecemeal move on to the platform. We can actually accommodate
your entire ecosystem in your entire stack. [MUSIC PLAYING]


Leave a Reply

Your email address will not be published. Required fields are marked *