(upbeat music)
- Welcome to the Azure Cosmos DB Essentials Series season 2.
My name is Mustafa,
and I'm a product marketing manager for Azure Cosmos DB.
In this season, we're going to dive
right into some key concepts
important for getting started with Cosmos.
Last season, we kept it pretty high level,
we talked about use cases, distributed databases,
and consistency.
In this season, we're going to dig one level deeper
and discuss foundational concepts
that you need to understand
to get the most out of Cosmos DB.
So in this episode,
we'll cover how to choose a Cosmos DB API,
as well as introduce the other concepts you need to know
on day one such as request units, schema design,
and partitioning strategy.
So let's get started.
When we go into the portal and create a new account,
the first thing we run into
is the concept of a Cosmos DB API.
Let's talk about how developers
should be thinking about our APIs.
The first question you want to think about
when choosing an API is,
am I building a new application
or migrating an existing application?
APIs are optimized around use cases
and effectively what Cosmos DB does
is it has a Core API which exposes the native engine,
and all Cosmos DB features as well
as offers service level agreements around performance.
And then there's also a set of open-source compatibility
APIs such as API for Mongo DB, Gremlin API,
Cassandra API and Table API,
created for people coming in
from those different environments.
If you're coming from Mongo Cassandra, Gremlin
or Azure Table Storage,
then the objective is pretty straightforward.
In order to minimize the amount of effort
needed to migrate into Cosmos DB,
we recommend a Cassandra user onboard
into the Cassandra API,
and the same for Gremlin, Mongo, and Table.
In contrast, if you're building a new application,
we recommend you use the Core API.
It has all the financially backed SLA's,
it's full of really useful features such as integrated cache
that are not available in the compatibility APIs.
And the primary advantage of using
the open-source compatibility APIs
is that they allow you to leverage existing skillset.
If your team is already ramped up on Cassandra,
Mongo or Gremlin, it offers you an ability
to onboard Azure Cosmos DB
without really having to learn something new.
Second, it also allows you to leverage
the existing ecosystem,
so if there's already tools or other frameworks
that developers are already used to,
it allows them to easily stick to that tooling.
And third, it also allows you to take advantage
of a diverse deployment strategy
by taking using similar APIs for on premise, hybrid
and multi-cloud deployments across different vendors.
So the decision matrix comes down to optimizing
around your existing configuration
or choosing to use the Core API
and take full advantage of the native Cosmos DB
engine's performance SLAs,
as well as additional features.
Okay, so now that we understand the factors
that influence whether to use a compatibility API
or the Core engine,
let's talk about some of the foundational concepts
we should know when getting started.
Once you've thought through what you're optimizing for,
there are a handful of things that every user should know
about Cosmos DB prior to building an application.
There are the things you need to think about on day one,
these have a huge impact on the performance, scale and costs
of the solution, and they're difficult to change
after the fact.
And there are things that we can change later
to further optimize our database.
On day one, we need to understand schema design
from the lens of normalization or denormalization,
we need to understand partition strategy
as well as the concept of a partition key,
and we also need to understand request units,
which are the way Cosmos DB measures compute.
So why is schema design so critical
in a distributed database?
Well the moment I start changing what my data model is,
the code is going to have dependencies on schema throughout.
If you're a C# or Java developer,
you're going to create a set of POCO or POJOs
and if you create these objects
and then decide to transition your schema
to a completely differently layout,
the business logic of your code will also have to shift.
This leads to a pretty drastic amount of effort
that we just want to avoid.
A similar thing happens in terms of partition strategy.
The partition strategy effectively
is going to be how we layout and give a placement hint
to show that this piece of data can be found
on node 1, node 2, or node 3.
If we go and change what that placement hint is,
you're basically taking data from node 1
and moving it to let's say node 2, 3, or 4.
Likewise, data from each of those other nodes
will also need to reshuffle.
Across these nodes, that's a heavyweight operation
and not something you generally want to have
on a live production runtime system.
Now Cosmos DB treats the partition key as immutable,
and should you want to reshuffle or re distribute the data
across a different partitioning strategy,
that would require a data migration.
So it's going to be really important to plan ahead,
and we'll spend
plenty of time to diving into schema design,
and partition strategy in the next few episodes.
Now to share a bit about request units, or RU's,
Developers looking at Cosmos DB pricing,
or who have already had a chance to jump into the portal,
probably first saw this concept of RU's and thought, what?
In a nutshell, a request unit or RU, is a form of compute.
Basically, behind the scenes in Cosmos DB,
what you're really getting is a fleet of nodes
that have some database software
and have some disks to go and store that store that data,
and requests units are the way that we put a number
on how much compute an operation costs.
Think of them like CPU cores;
depending on whether you have one CPU core
versus a million cores,
you're going to get a variety
of different performance and costs characteristics.
The more compute available,
the more throughput you can get out of your system,
but at the same time,
it's going to get more and more expensive,
the more compute is available.
Request units are different from CPU cores
because when provisioning hardware,
you can't purchase a fraction of a core.
However, RU's make it possible by focusing
on the compute effort rather than the actual hardware.
Azure Cosmos DB has a few pricing options
that use RU's.
Lets quickly introduce those as well.
We have Autoscale and standard provisioned throughput,
as well as Serverless.
Throughput provisioning tends to be a goldilocks problem
where you want to get it just right.
If you overprovision, you'll have all the compute
on the cloud available, but it's not cost effective
because you're paying for unused capacity.
If you underprovision,
then it may not be optimal from a performance standpoint,
but you won't have to spend any money.
Each of the models I just mentioned offer a set of benefits
depending on the use case
and we'll dive into that on the RU episode.
So to bring us back to the previous thread,
things we should know on day one are
how we're going to design our schema,
how we're going to partition our data,
and how to think about request units.
Some of the other important topics developers
should understand eventually,
but aren't necessarily a big headache to change
once you get the other three rights,
are things like indexing, security features
such as IP firewall, monitoring, consistency.
Things like this are important
to database optimization and security,
but are fairly easy to change after the fact.
All right, so that concludes the first episode.
We discussed how to think about the APIs,
and considerations when building new apps
or migrating existing workloads with Cosmos DB.
We also introduced some of the foundational concepts
for getting the most out of Cosmos DB
regardless of which API you choose:
Schema design, partition strategy, and request units.
Join me in the next three episodes
to dive into things to know on day on in depth,
starting with the upcoming episode on request units.
(upbeat music)