>> You've learned about Azure SQL Database and Developers.
In this part 2, we'll go even deeper on some of
the architectures of Azure SQL Database
on this episode of Data Exposed.
[MUSIC]
>> Hi, I'm Anna Hoffman and welcome
to this episode of Data Exposed,
where we continue to expand on why
Azure SQL Database is the best database for developers.
I'm once again joined by Davide Mauri,
a Program Manager on the SQL Database team. Welcome back.
>> Hey, Anna. Thank you. It's a pleasure again to be here.
>> Thanks for being here again.
Today we're going to dive a little bit
more into some of the architecture,
so I think you had some examples
that you're going to share with us today.
>> Yeah. Right. Let me go straight to it.
So again, I prefer just couple of slides
and let's just go right to the point.
>> Sure.
>> The idea today is to discuss with you some of architecture we
saw applied successfully with Azure SQL.
The first is related to the latest offering of Azure SQL.
We have the Azure SQL Hyperscale that enable,
I would say next three scale-out scenario.
So let's say you have a mobile application, or API,
or any write-heavy solution and
you want to land all these data as fast as
possible in Azure SQL Hyperscale.
So you can do that, as usual,
Hyperscale can ingest data up to 100 terabytes,
so you are not worried about scale.
But what you are worried about is that
enough clients can connect at the same time and consume that data.
So they don't want maybe to write data anymore,
but they want to read the data.
These are typical use case scenario when you have OLTP,
where you have like 20,
30 percent writes, and the majority,
the rest is read.
For example, let's say you have
a gaming application that is running on an Xbox and
you have many people joining and using your massive online game.
So they need to be able to query data about
the item they have or where they are
in the virtual world, whatever.
At the same time,
you also want to have administrator of this game being
able to do some real-time analytics,
or HTAP as it's called today.
So you have a very different workload between very fast and short
reads that happen on a mobile or a console device,
and then more complex and more analytical queries that happens on
Power BI or any other solution
that you may want to use to do analytics.
With Hyperscale, we can have,
today, up to four replica,
but we are working to improve that limit to much higher values.
What will happen is that you will immediately have available
up to four read-only replicas that will read
exactly from the same data source,
from the same page server that how data is stored in Hyperscale,
not in file, in but in servers,
in microservices for storage.
We'll read exactly from the same place where data is also written.
I would say there is no latency between the fact that
an API writes into the primary node,
the Hyperscale node, and
the secondary replica allows you to read that data.
Hyperscale replicas can grow
horizontally and so scale out very quickly,
and can support a huge number
of queries per second or connection per second.
Also, these allows you to differentiate,
as I said before, small,
fast read on a couple of secondary node and
other more complex workload
the type of analytical queries into another one.
So this was not something
that can be easily done before Hyperscale.
Thanks to the new architecture we have,
this really enables huge scale out scenario.
Talking about scale out
and another complex thing that we can do, of course,
another common request is to do demand analytics,
or forecasting, or create a recommendation solution.
Here you have a complete architecture of what you can
do using many of the features
available in Azure as
a complete Cloud service
that fits together very nice with Azure SQL.
So you can have a Web Storefront,
some API that your customer want to query,
your integration with local file,
files exported by existing ERP,
warehouse and IoT, that all flows into Azure SQL.
Probably they are going to use
the transactional part of your SQL Rowstore.
At the same time, the same rowstore can
also be used as a columnstore without data movement,
without copying data somewhere,
without having to duplicate the data,
which usually would introduce some latency.
But on the same table,
you can have the transaction rowstore storage
and your analytical column-store.
Of course, this will enable all the analytical processing in
near real-time because as soon as you write,
you can also read from the analytical part of it.
Everything happens also with
the scale out option that we saw before.
So really, there is an incredible opportunity here to
create something that just a few years
ago was almost impossible really [inaudible]
>> Yeah. It seems like also a lot of
these things are just easy for me to set up, right?
>> Yes.
>> It's not like I'm having to create
these architectures and deploy a bunch of custom code,
a lot of the integrations are already there.
>> Right. Especially for the HTAP scenarios,
you really don't have to do anything because Azure SQL,
it will automatically use the rowstore or the columnstore,
depending on the query you write.
This is because we have a query processor
that has been optimizing the last 30 years.
So I would say now it's quite smart to
understand what is the best code for you.
>> Yeah. Awesome.
>> Yeah. Talking about
real-time and complex things
that now are much easier, for example,
personalization and fraud detection is
a common requirement today to make sure that you have,
as a user, a personalized experience and at the same time,
companies can detect fraud as soon as possible.
This is another example where
the transaction rowstore and
the analytical rowstore works very well together.
Not only it is, as you can see,
a very simple architecture,
you just log your data into
Azure SQL using your transactional rowstore and I'd say,
automatically for you, it turn it into
a columnstore that can be used by
analytics or monitoring and another thing.
As you can see, the architecture is very simple.
We have a couple of customer that we
just did a case study with them that are using,
ideally, these architecture to exactly do
fraud detection and impersonalization.
So ClearSale is one.
They are using Hyperscale and as you can see in the solution,
[inaudible] Azure function to
basically do exactly that, fraud prevention.
So this is one customer that
is successfully using the architecture which has discussed.
Another one is Clearrent.
This study is validating credit card transaction.
It's another important business
where you don't know how much you can
grow and that's why they
decided to go with Hyperscale because again,
they can grow up to 100 terabytes without any problem.
That is well integrated with
the whole Azure Infrastructure because it allows to ingest data,
process it, and consume it using Power BI, for example.
So I think these shows
how flexible and how well integrated this Azure SQL
within complex ecosystem like
Azure and that allows you to really create complex solution with,
I would say a minimal effort
compared to what was possible in the past.
>> Thanks so much. I think you've really shown us not
only that the possibilities are endless, but that also,
people are already investing
and putting these architectures into practice.
>> Yeah.
>> I think that's really powerful.
So thanks for sharing it with us.
I think we have some references that
we'll share in the description.
Thanks for joining us today on Data Exposed.
Be sure to like this video, or subscribe,
or comment and let us know what you're
using Azure SQL Database for.
[MUSIC]