Azure SQL Capacity Planning is very important to make
sure you're optimizing not only your costs
but also your performance.
In this video, we'll dive into an overview of what that entails.
[MUSIC].
Hi, welcome to this episode of Data Exposed.
Today we're going to be talking about an overview of
Azure SQL Capacity Planning and today
I'm lucky to have with me joined all the way from Italy,
Silvano, PM on the Azure SQL database team.
Thanks for joining us today.
>> Thanks a lot Anna for having me. Glad to be here.
>> Awesome. Just to kick this off and set some ground setting,
I wanted to ask when we talk about capacity planning,
what does that really mean and why is it important?
>> Capacity planning is the process
where you are actually trying to estimate and figure
out what is the required amount of resources
in your system to be able to run a given workload.
Every time you are designing and
implementing a brand new application and you are thinking
about the deployment phase when
your applications will actually go to
production or every time you are planning to
move from an existing system to a different one,
like for example, from your on-premises deployment
for SQL Server into Azure SQL database,
you need to actually start thinking about
what will be the amount of resources,
and sizing and technically
capacity planning will be
needed in order to make sure your deployments would be successful.
>> Awesome. It seems straightforward enough.
Like any type of product or process,
we want to make sure that we're planning appropriately and we have
the right capacity for the workloads that we're running.
Now, when it comes specifically to Azure SQL database,
what are some of the things that someone should consider?
>> Especially for people coming from
the traditional on-premises space,
where you have a potentially infinite set
of options in terms of configuring your hardware,
your system, things like
the amount of SSD disks that you're throwing into your system,
the storage configuration, CPUs and such.
When it comes to a PaaS offer like Azure SQL database,
you have a set of bundled offers,
where you have to select from,
reduce the amount of options and flavors.
The ability to translate from
an existing system that is sitting in your own data center into
this set of predefined bundles
in terms of the resources like CPU cores,
memory, and I/O is critical actually and effectively,
is the most complex decisions that you have to take.
>> Thanks Silvano. It seems like
this is a really important decision.
Can you walk us through some
of the things or dimensions that we should consider?
>> Absolutely. Again, in a PaaS offering like Azure SQL database,
we have this reduced set of options where we can
decide basically on which one to deploy our workloads.
Those dimensions generally starts
from the deployment options that we
have available in Azure SQL database,
so we can pick up from single database instances,
elastic pool, where we have a group
of databases that are sharing the same set of resources.
We also have the new serverless compute tier available,
where you can basically accommodate
the spiky workloads and let the service itself
to manage things like auto-scaling
and always using the right amount of resources behind the scenes.
We have Azure SQL managed
instance for customers that wants to basically have
the closest behaviors to
the traditional instance-based SQL Server deployment
that we know and love on-premises.
Once we decide which one to pick between these deployment options,
we moved into this concept of purchasing motors.
We are offering two models here because one,
the DTU stands for Database Throughput Units
is targeting customers that are brand new into
their own applications and they don't have
existing set of preferences
like an existing system with a given amount of cores,
memory and I/O configuration.
But they just are thinking in terms of what is the amount
of concurrent users that I have and
how many transactions per seconds they are
expected to run against my system.
DTU is a model which is designed around
this concept of simplifying essentially
the configuration of your Azure SQL database instance
by picking up the amount of throughput units that you will need.
The vCore purchasing model is instead
much more similar to what you typically do in your on-prem space,
where you buy a given amount of cores,
memory and I/O throughput and then you can,
for example, compare and contrast with what you
have on on-prem and start basically the sizing process from there.
The next dimension in this process is to try to figure out,
what is the service tier or the level of
service that we are expecting from our database?
In the DTU purchasing model,
we are basically classifying
our service tiers between basic, standard, and premium.
Where basic, as the name imply,
there's the minimum amount of resources available for you,
while the premium is offering
much more resources and
throughput units for running your databases.
On the vCore based purchasing model,
we are dividing essentially those service tiers
in general purpose and business critical.
Again, general purpose is for running
your regular database workload.
While business critical is offering reduced latency and a number
of advanced characteristics even in terms of feature set.
Hyperscale is the new service tier
that we've been introducing recently,
which is actually providing a brand new storage engine into
the Azure SQL Word and is actually promising
infinite scale in terms of data volume that it can accommodate and
basically giving you the ability to
scale your largest workloads actually.
For all these different service tiers,
we have different compute sizes
that are effectively defining the amount of resources like CPU,
storage, and memory you will get and each of
these compute sizes comes with
its own set of resource limits and characteristics.
The capacity planning process in Azure SQL DB will at
the end require you to pick up between these different dimensions,
the ones that is effectively capable
of running your workload now and in the future.
>> Thanks Silvano. That was really useful to see how
these different choices are broken down.
But really we're just skimming the surface on this topic, right?
>> Absolutely, and over the next episodes in this series,
we will go through
some practical recommendations and
suggestions on how to basically,
go through this capacities planning
process in order to get the amount of
information you need before you are
actually deploying your Azure SQL database instances.
>> Awesome. Well, thanks so much,
Silvano, and if you like this video, please,
like this video, leave us a comment and stay
tuned for the next part in Azure SQL capacity planning.
[MUSIC]