(bright music)
Hello and welcome.
Please enjoy this short, readiness video
on Azure Cosmos DB.
Hi Tim.
How are you doing today?
Hey, how are you Sanjay?
All right.
So great to have you with us.
Yeah.
Let's get started.
What are you going to talk about?
Cool.
So I'm a program manager on
the Cosmos DB engineering team.
We're gonna cover pricing today, in Cosmos DB.
So, first thing we'll do, is we'll just introduce
how pricing works in Cosmos DB.
I know it's a little different
than a lot of other databases out there.
And pricing is important.
It's very important, right.
And we'll talk about a lot
of the technical component as well.
And really focus in on what request units are,
and why they're really important to understand.
And also, obviously, focusing on ways to reduce cost,
and ways to reduce the number of request units.
All right.
Let's get started.
Yeah.
So there's two components of your bill
in Azure Cosmos DB.
The storage you consume
and the throughput that you provision.
So, in Cosmos DB, we basically just bill you
on consumed storage.
So it's really simple.
If you start out with a database
that has zero GB of data,
your bill for storage is essentially zero.
And as you add more data in,
we just bill you automatically.
For most regions it's 25 cents per gigabyte, per month.
So, as a Cosmos DB developer,
you don't even have to think about
how much data you're storing, at all.
Now, request units are a little different.
For request units, you provision
the number of request units that you want.
And Cosmos DB is really cool because
it's a highly available service that guarantees
that those request units are available.
With five nines of availability.
So that means if you provision,
let's say a million request units,
and you're a big customer on,
let's say Black Friday, Cyber Monday, kind of thing,
this time of year.
If you provision a million request units,
those are guaranteed to you.
So we basically set aside that capacity,
specifically for you.
Specifically for you Sanjay.
All right.
For your big retail company.
But those are billed at about eight tenths
of a US cent per hour for most Azure regions.
Now with request units,
you're billed on what you provisioned.
So, just like with any other database,
it's important to scale it appropriately.
Right.
So you wanna ensure,
to get good value out of Cosmos DB,
that you have the right amount
of request units provisioned.
So what is a request unit?
Yeah, absolutely, that's a really great question.
Request units are basically a rate based currency
to do reads and writes inquiries, and things like that.
So a lot of data bases, you'll, if you were let's say
hosting a database on a VM.
There'd be many different bottlenecks to worry about.
Memory, CPU, IOPS, like these could all be
the bottlenecks as you're doing
many reads and writes to your database.
And if, let's say, you own a big retail company,
or a big company, on Black Friday,
Cyber Monday, if any of these are the bottlenecks,
you're gonna have, like, performance issues.
Right.
And you're gonna really need
to worry about scaling easily.
Now with the Cosmos DB,
we have one unit that basically
extracts all of this.
And that's request units.
Okay, that's good.
You wanna think of them
as basically a currency that you can use
for database operation.
So let's say you have a write.
And a write takes 10 request units or RU's,
and you need to do that write 10 times.
How many request units do you think you'd need?
A 100.
A 100, right.
10 times 10.
So, really simple math.
Really simple concept.
And really easy to plan and understand
when you use them.
I see, okay.
So, what about, can't we manage
all this, sort of automatically?
Yeah, absolutely.
So obviously you do have the option to manually
modify request units.
Yes.
Whenever you'd like.
Let me go back here.
Jump to a quick demo
I have to highlight that.
Oh.
Wow, you're gonna show how to use an action?
Absolutely.
So here I've created a Cosmos DB container
that has nutrition data.
And I provisioned 400 RU's.
Yeah.
So as Andrew showed earlier,
if I wanted to, let's say,
scale up to 10 thousand RU's,
I could do that really easily.
Yeah.
And the change is instant.
Right, super fast.
But you might not want to even worry about this.
Right, you might want it,
basically, managed automatically by the service.
Another good option you have,
is create a container with the new feature
we have called Autopilot.
Autopilot.
Autopilot.
So I'll name this new container.
Just partition it on ID.
And come down here, and right now,
by default, we're still picking the manual setting.
But, if I come over to Autopilot,
I can choose a maximum number of RU's
that I wanna scale to.
Yes.
So I'll just pick 4000.
And essentially I'll scale between
this maximum number of RU's
and 10% of the value.
So I'll scale between 400 and 4000 RU's.
Cosmos DB will manage this automatically.
And as a developer,
you actually don't really
have to explicitly think
about scale.
That's great.
Which is pretty cool.
Those features are all available.
Yes.
It's in preview right now.
We announced the preview at Ignite.
Okay.
So, awesome way to have RU's
basically managed automatically for you.
I see.
Now, we also have, newly available,
an awesome calculator for estimating capacity.
Yes.
So if you don't wanna have to think about capacity,
that Autopilot feature's really awesome.
But if you do wanna get a sense of capacity,
RU needs, and costs in advance,
this calculator's pretty cool.
I see.
So we're gonna walk through a quick,
kinda sample together
Yeah.
And mess with the calculator a little bit to see
how different factors
Okay.
effect the total cost.
So I just have a sample.
Cosmos DB collection in let's say,
one region with our Sequel API, our core API.
To keep it simple, I'm gonna turn off multi-region writes.
If I were to turn it on,
and you have multi-regions or multi-region rights,
keep in mind multi-region writes
are billed at a higher rate for RU's.
And then when you add Cosmos DB to multiple regions,
we store a full copy of your data in each region.
So it basically just be increasing
the total amount of storage in RU's.
But to keep it simple.
We'll just do one region.
Keep session consistency at default.
We'll leave indexing at automatic.
So just by default indexing every property.
And let's say we have a 100 gigabytes of data.
So, reasonably small workload.
We can specify the document size.
So in Cosmos DB, your data's modeled in JSON.
Of course.
What size do you think we should specify here?
You can pick any number you like.
100.
100 kilobytes?
Okay, so that's actually a pretty big JSON document
so I'll dial it up to 100.
Uh oh.
Which is pretty big.
In general best practice for no Sequel databases
is to keep your JSON document small.
So if it's ever possible.
We'll check the big one,
and then we'll check a smaller one
to see what impacts the charge.
So in a no Sequel database,
if you have a really large documents,
the cost for doing writes is gonna be much higher.
Right.
It's a bigger amount of data.
More properties to index, that kinda thing.
So the pattern we recommend,
is if you have things like images,
really big parts of data, ginorays.
You want to store the metadata
in Cosmos DB to go and search on.
And then store like the big parts
of the document that are storing
a lot of data, like images, for example,
videos, store that in Azure BOB storage,
and then link to it.
I see.
So with this scenario,
let's say we do a 1000 reads per second,
300 writes per second.
And we go an calculate the cost.
The cost is actually gonna be pretty high
for this small workload if we have
100 kilobytes of document.
That's about 14 thousand US dollars
and we need, to do those rights,
about 16 thousand RU's.
Now I'm gonna dial it back down
to a pretty small size.
Pretty small one KB documents.
Real world scenario.
Re-compute the cost.
And this is realistically what customers would have.
No Sequel databases.
Small documents are gonna give you great performance,
and of course the cost
is really economical.
Yes.
And if I were to, let's say scale up,
to 10 thousand reads per second,
and 10 thousand writes per second,
even scaling up by this great a number,
the cost for Cosmos DB is still very economical.
And great value if you're doing
a lot of reads and writes
against your data.
That makes sense.
Awesome.
So what if I provision too many RU's?
So if you provision too many RU's,
and before I talk about that,
I wanna talk about queries
in Cosmos DB.
Of course.
And how you can estimate the cost for that.
So, of course with this demo,
I basically was just showing simple reads and writes.
The idea here is if you had something more complex now.
If you had like a complex query
that you had to go run against your data.
You want to actually go run that sample request
instead of using the calculator.
So the calculator is designed to be simple.
Right.
Easy to use.
But if you really wanna get a precise estimate of cost,
I'd actually recommend going in the Azure portal,
running sample queries,
and going and figuring out the RU charge for them.
And in Cosmos DB, we make the guarantee
that if you run the same query multiple times,
against the same data,
the RU charge is always gonna be the same.
So if I just list out here
that I'm doing these top three queries,
10 thousand sample writes.
List out the number of RU's per second.
I can quickly kinda do some math
to figure out an approximation
of the number of total RU's that I need.
Makes sense.
I come to the Azure portal,
it's actually incredibly easy
to figure out the RU charge for a query.
If I just add a new Sequel query here.
I can quickly go and observe
the total request charge.
And see that this one is 47 RU.
So that math is really simple.
But to answer your previous question.
How do you know if you have
the right number of request units provisioned?
Right.
It's a very important question to understand.
You can come to Metrics.
So if you scroll down here,
to the Metrics blade of the Azure portal.
Come to the Throughput section.
You could actually view the number of requests
sent to your Cosmos DB container.
And also, ultimately view how many
request units you are consuming.
So if you're using the Autopilot feature,
will scale up and down based on what you're consuming.
If you're not using the Autopilot feature,
and you're manually scaling throughput,
either programmatically or through the portal,
this is a great place to go,
to look at how much throughput
you're ultimately utilizing in your
Cosmos DB container.
Fantastic.
Any closing thoughts?
Yeah.
Cosmos DB is a great value for doing reads and writes.
And it's really priced optimally
for really request heavy workloads.
So workloads that have a ton of requests,
but don't necessarily have amount of data,
have a lot of data.
These are great fits for Cosmos DB.
Thank you so much for your time today, Tim.
Absolutely.
Thanks Sanjay.
Thanks for watching this short
Azure readiness video.
