>> Learn how you can build
a really performant Leaderboard for the World Cup
using Azure SQL and
Redis or for a lot of different things as well.
This week on Data Exposed.
[MUSIC]
>> Hi, I'm Anna Hoffman and welcome
to this episode of Data Exposed.
Today we have an exciting episode plan.
We have joining us today,
Davide from the Azure SQL Product Group.
He's been on the show lots of times, welcome Davide.
We also have Roberto,
our special guest joining us from elsewhere.
Roberto, can you kick us off by
telling us a little bit about what you do?
>> Yes. My name is Roberto Perez,
I'm a Senior Partner Solutions Architect with Redis
pretty much 18 years of
experience building application, doing solutions, architecture.
>> Awesome, cool. Well, I'm really
excited about this episode because we're going to be
talking about how to build
a real-time Leaderboard for
the World Cup using Azure SQL and Redis.
For folks who might be a little familiar with
either solution or maybe with either solution,
I thought it might be good if we started off with what is Redis,
how does it relate to Azure,
how it is really to Azure SQL?
Can you-all help me that?
>> Yes, definitely. Azure Cache
for Redis Enterprise is a partnership.
Redis and Microsoft has a partnership where seniors engineers
from Redis and engineers from Microsoft are joining together,
working together for creating this amazing product.
Azure Cache Enterprise,
you will have Active Geo-Replication,
you will be able to use the modules or RediSearch, Bloom,
TimeSeries and JSON,
if you guys need to find nine desolate,
that's also available for you and ability to have
a private link, this joint support.
Microsoft will have the Tier 1
or that right there for the clients.
Clients will submit the tickets,
Microsoft will respond,
and then there is a backup or direct line.
If there's any type of escalation,
Microsoft will contact Redis and they
will do the most effort to solve that problem.
Now, there is different use cases
that most people are familiar with when we talk about caching.
The user session store,
that's the most common one.
Or even storing any type of string caching,
when there's for example the token, if you want to store that.
But Redis enterprise you can
use for either a lot of more use cases.
You can do content caching,
you can do time series, notifications,
search, geo-spatial data, you name it.
Definitely, you can expand the use cases and apply
for a lot of more solutions to your problems.
>> Let me talk about Azure SQL a little bit now.
I just want to highlight that we decided to go with
Azure SQL because we believe
it's the best database for developers.
It offers a wide range of option to make
sure that you can do relational multi-model.
You get the same engine working from edge-to-Cloud.
You have a multi-version concurrency control
so very high concurrency without
having to wait a lot for example encryption,
which is pretty important these day.
It's available everywhere, transparently, at rest and in flight.
We have had a very,
very rich query optimizer with a lot of
features that can help really to build any application.
We just actually released the 128vCore for hyperscale.
You can almost illiteracely scale out and
you can go up to 100 tb and upto 30 replicas.
You can really handle any workload.
Here you can find an article I wrote sometimes a go on
the 10 reason why you should use Azure SQL for your next project.
>> Awesome, cool. Before we go any further,
I think I've learned a lot so far about why you
might use Redis and why you might use these things together.
I think I know where we're going with the leaderboard,
but I want to make sure you guys answer,
how can I use this for
a modern app like tracking the scores of the World Cup?
>> That's a very interesting question.
Well, the first answer that I can give you is teamwork,
because there is no one Database that will fit the need of
serving one billion users watching the results of the World Cup,
and being able to have reached query capabilities,
and at the same time, the worldwide geo-distributed.
Team work exactly as it happens in the World Cup is a key here.
That's why we partnered with Redis because we want to
build a modern application that has low-latency,
that's provides a rich query capabilities to do all the statistics
that people are passionate about soccer and may want to do.
Of course, from a cost perspective,
you provide an optimal cost in
performance for those who are posting the application.
From a developer perspective,
we also want to be able to quickly
improve enabled application adding new features,
and so it needs to be agile and
evolutionary or at least support this paradigm.
That's why we went with
the solution architecture that you will be seeing here.
Roberto you want to take a stab at it?
>> Yeah, definitely. Right here when you deploy the applicaion,
you normally have global load balancer.
In this case, when you see the application,
you would be able to go through the bicep
and it was going to deploy a global load balancer.
Then you have the App Service and right
now the app service you will deploy one is East region,
one is West region.
You also will find two Azure Functions.
One is going to be used for the right behind pattern that we'll
implement and the other one will use the little pattern.
The same to store the data.
You have a active-active GO replicated cache layer where you
have a ready cluster on the East and a ready cluster on the West.
To store our application data,
you have Azure SQL database.
>> Roberto just a quick question here make sure that it's clear.
Basically, we are using Redis,
we have the hot data,
closer as possible to the end-user
while SQL to basically get the audience changes that
happened on the consolidating in a single place
so as an analyst for example I can do any complex goal.
Maybe then sending vector,
these two products to
these people or anything like that is been right?
>> That's right. You will place
the cash layer on front so they use
or have fast data queries, reading.data over.
Then there's a right behind pattern that is
going to take that data out to
Azure SQL so you can run any type of
analytics or any other things that you may want to.
>> Let's go to the guess
or we have something else that you want to show?
>> Yeah, we can talk a little bit about what's a leaderboard?
In our case definitely we can see in the World Cup,
but you can find this leaderboard in different industries.
You have financial services on stock market fluctuations.
Music like billboards definitely is a very,
very common pattern or thing that you will see
everywhere that's what we can see.
>> Cool, this is really awesome.
Let's take a look at a demo if there is one.
>> Yes and one thing.
I think when we try to put together the demo,
we tried to avoid some legal problems with world cup,
so we switched it to 100 dataset.
But I think the learning and the demo will apply
exactly the same way if we want to
do any leaderboard that you mentioned.
>> Yes, that's correct.
>> That's cool.
>> Right here, you'll see there is the top companies.
We have a set of different companies with
their market cap and their country.
As you mentioned, we could switch that to
show anything as the World Cup,
the teams, there are flags, their logos,
and how many wins or losses they have?
>> But we want to be friendly with our legal department.
>> Exactly. Here we have the company data.
We're showing the name,
the logo, the market cap and the country.
Pretty much you can update
the actual company market to whatever the different amounts.
In this case we can update to 10 million.
Before I do that, I want to show a really quick,
we have different feature flags,
configurations that we can use when you go to your repository.
One of them is AllowAdmin.
You'll need this one if you want to delete the keys when
you are starting the application for the first time.
The next thing you have DeleteAllKeys,
that's if you really want to delete the keys.
On Application, Start, Load initial data.
When you start application it's going to load our data set,
you're most welcome to bring any data set.
You have the UseReadThrough and UseWriteBehind,
and those is to use
the WriteBehind pattern or the ReadThrough pattern.
Here is the URL for the ReadThrough function.
Let's go ahead, I'm going to show the Azure SQL database.
I already pre-populated the data beforehand.
I launched the application.
It went through and loaded all the keys.
If I can see here,
I do a select, I can see all the companies and the market cap.
Here we have the top 10 companies.
We're going to go ahead and update their rank right here.
I'm going to select apple,
I'm going to update it to 10 billions and click "Update".
What is happening is,
right now we're updating straight to
the catch and we're getting the data back from the cache.
Then we have an Azure Function that
is running there right behind pattern.
Asynchronously it's going to take that data,
it's going to move it to Azure SQL.
Let's go ahead and show us.
It was pretty fast right here.
Before we have the 2.2 billion market cap,
and right now we have the 10 billion market cap.
As you can see,
this is the one of the best ways to do that, right behind pattern.
>> Awesome, cool. Thanks so much for showing us this Roberto.
This is super neat demo.
Davide thanks for showing us how it ties in with
Azure as SQL a great combo, great partnership.
The best part about all of this for our viewers is that
all the sample code that you saw is available
today and it was a blog for you to go look at.
If you like this, you want to learn more about it,
you want to check the description for links to learn more,
if you like this episode,
go ahead and give it a like leave us a comment and
let us know what your favorite part is.
We hope to see you next time on Data Exposed.
[MUSIC]