>> Learn about some of the performance gains you get with
Azure Database for my sequel, flexible server,
including a cool demo which also touches on
maintenance Windows this week on Data Exposed.
[MUSIC]
>> Hi, I'm Anna Hoffman and welcome to
this episode of Data Exposed.
Today I have joining me a special guest,
Bashar, from the Azure database for MySQL team.
Bashar, thanks so much for joining us on the show today.
Can you tell us a little bit about what you do?
>> Hey, Anna, thanks for having me here.
My name is Bashar and I'm a Senior Product Manager in
the Azure database from MySQL flexible server Team.
My charter includes performance,
maintenance Windows, major and minor version upgrade,
pricing, along with supportability of the product.
>> Awesome. Great. It seems like you are
the perfect person for what we're going to talk about today.
We're going to be talking about some of
these things related to performance.
But before we get into it,
I wanted to ask you,
why should customers that are
either not using flexible server today
or using Azure database for MySQL single server,
why should they consider using
Azure database for MySQL flexible server?
>> Basically flexible server was designed for providing
more granular control for users over
their database management operations and control.
Basically we've heard the feedback
coming on the Azure single server
and we decided to build an architecture
which offers the customer better performance,
more granularity, and
better management of this database server itself.
Basically, a flexible server will come
with a lot of features that customers will be
looking for to have a better performance predictability in terms
of monthly maintenance windows and
along with co-location between database and application.
>> Awesome. Cool. If we wanted to dig a little deeper,
can you share with us how Microsoft went about actually building
a more performant of this community open source MySQL?
>> That's a great question. First thing for
us was that we wanted to ensure that this will be
an fully open source database
so customers can easily migrate to the flexible server.
On top of that, we've decided that we will reduce
the number of hops between application and database,
so we removed gateways in between the application and database.
The application connects directly to the database.
Also we allowed users to decide
which availability zone they
want their database and their storage to be in.
The Azure virtual machines also allows
this capability so basically customers
can locate their application,
their database, and their storage in the same zone,
which significantly reduce latency.
On top of that, we decoupled the storage from the IOPS.
Basically in single server,
if your workload requires more IOPS,
you scale up storage and then you'll get more IOPS.
Basically it was each one gigabyte, three IOPS.
This offers a challenge for customers because by default,
the community version of MySQL does not allow you to shrink files.
Basically you can scale up storage,
you cannot scale down storage,
and that was a huge limitation.
What we did, we decoupled storage files.
The workload requires more IO intense workload.
You just scale up IOPS and then you can later scale it back down.
Another thing that we did,
we decoupled the number of
vCores from the max number of connections.
Some workloads, some applications require higher number of
connections to connect concurrently to
the database server and we decoupled those.
Flexible server offers higher number of
active connections to [inaudible] on the same server.
>> Cool, thanks. If I could just recap,
really comes into two big bigger things
that improve the performance.
One is the ability to co-locate things in the same zone,
which is actually huge because folks coming
from on prem or somewhere else are used
to all these things being right next to each other and now you
can do the same thing in the Cloud by putting your VM,
your app, and your database in the same zone.
That's awesome. The other thing I
heard was around independent scaling.
Now you have the ability to scale your compute,
your IOPS and other things really independently of one another
without having to scale up vCores for example to get more users.
That's really awesome. I know you all are also doing
some things in the maintenance window space.
Could you share a brief of what maintenance windows are and then
also what's new for Azure database for MySQL flexible server?
>> Sure. That's a great question.
Basically Azure database from a SQL flexible server,
as we said, fully managed database service,
which means that we are giving a lot of
background operations that we are helping users with
basically patching the servers with the latest and
the greatest bits for that operating system, the database system.
We're adding features, improving performance along with
other bits that we are shipping every month to ensure compliance,
privacy, security for our customers.
Basically all those operations needs to go in on
the database and the database requires a restart.
In single server, we used to send
notification to customers three days ahead that
there would be a restart on your server in
the following 16 hours window.
Their search will only take less than a second,
maybe up to three, four seconds.
Really depends on the transactions that the user is running.
The problem with this feature that some customers would
have a workload that
they need to run during those 16 hours window.
It reduces the predictability for them.
Now in flexible server,
the cool thing is that the customer can decide a custom window
the day of the week that they need
this patch to happen in and only one hour window.
They will go on Friday midnight.
The restart will happen during this hour.
Also what we are shipping with the maintenance
Windows for flexible server, a version upgrade.
We're taking care of those for the users
along with the capability for the customer to
decide if they want to pause or they want to
resume or the maintenance to happen.
This gives more flexibility to the users that they
can decide when to patch their servers with the latest bits.
>> Got you. Flexible server isn't
just about flexibility when it comes to performance,
but also flexibility playing on
a flexible word for things like maintenance windows.
It's really awesome to hear
all this stuff happening in the MySQL space here.
I think you might have a demo.
It would be awesome to see some of this in action.
>> Just before I play the demo,
there's one thing I would like to point out.
In flexible server, there are three performance tiers for users.
First of all, general purpose and memory optimize.
The ability for flexibility gives the customer
so many combinations and they can choose
which performance tier they want to run on.
Basically, burstible SKUs are for workloads that will not
require full CPU all the day so they can use the bursting of CPU.
General purpose is better for workload,
which is mid-tier workload balance between
the vCores and the memory with a scalable IOPS.
They are a little bit more IO intense.
They can go higher with the IOPS with
the same memory and vCores CPU processing.
Now for the memory optimize,
they will get tier one workloads
which require more in memory operations.
This will be really cool because they can balance
between in-memory operations and IO intense workloads.
Now I think we can go to the demo.
I'll show the differences in terms
of throughput latency between a single server and flexible server.
Basically this is the workbench.
I'm running workbench from this West US 2 VM.
It has a 8v Core and a 32 gig memory.
Basically, this is the single server which we are running on.
Same 16 vCore.
Basically this single server that I will show,
it's in West US 2.
As you can see here, 16 vCore and it
has eight terabyte and 20,000 IOPS.
Basically you can go all the way to 20,000 IOPS.
For this test, I did 20,000 IOPS just to get the more IOPS.
But you can scale up and down storage.
Basically a storage and IOPS are
related here because it's single server.
Now, this is the flexible server and this has also
16 vCore and same memory,
eight terabytes for storage.
It's running in West US 2.
If you look at compute and storage,
here you have IOPS like there.
All the way to 20,000 IOPS.
But storage, I can decide how much storage I want.
This is a better performance at a price.
Now, if you look at the workbench
that I just ran before this demo,
so basically for 360 seconds and 250 threads concurrently.
As you can see here on the single server,
I was able to get around 64K,
sorry, QPS per second.
Basically the latency was around 632 milliseconds.
Now we are trying to compare with
the flexible server running the same test,
360 seconds, 250 threads,
and same server that I just showed you.
Basically here we were able to get 115K QPS per second,
which is a huge gain compared to
the single server for the same SKU.
The latency was much,
much lower for 43,
thanks for that co-location.
Now if you look back 64K and 632 on the single server,
so it's a huge gain because of the co-location
and the performance updates that we have done.
Now talking about the maintenance window, as you can see here,
in terms of maintenance,
the customer can choose between system
manage schedule and the custom schedule.
The custom schedule, you can choose the day of the week.
As I said before,
you can choose which day of the week you want to run
the maintenance and then just click on
the day and then decide the time that you want
the maintenance to happen in and click "Save".
That would save the maintenance.
You have predictability in
terms of when the maintenance will happen.
>> Awesome. Cool. That's a great demo which I was
really cool to see how much the performance
improves and then also how you were able to put the database,
I'm sorry, in the same zone as
the VM that you were running the test in,
which probably also I'm guessing was
a big factor in improving the latency there.
Bashar as we close out this video,
do you have any final words of
advice or tips and tricks for folks that are
just getting started with
Azure Database for MySQL flexible server.
>> Yes, sure. Basically,
we are doing our best to send all the tips and tricks for
the Azure flexible server on
our blog so please follow our blog channel.
We are posting a lot of hacks and tips,
tricks to get better performance.
As I said, flexible server offers
a lot of flexibility to customers,
which makes sometimes in scenarios
where which is the best one to go for.
We will have all those in our blogs.
Enjoy using flexible, etc.
and thank you so much for considering as
a database for MySQL flexible server.
>> Awesome. Thanks so much, Bashar.
Thanks to our viewers for tuning in.
If you like this video, go ahead, give it a like.
Check the links in the description,
including the blog for
the flexible server team and we
hope to see you next time on Data Exposed.
[MUSIC]