(smooth music)
- Welcome to the Azure Cosmos DB essentials series.
My name is Mustafa and I'm the technical product
marketing manager for Azure Cosmos DB.
Now, throughout this series,
we'll discuss Cosmos DB concepts,
tips, tricks for both beginners
and expert level Azure Cosmos DB developers.
Season one will focus on the basics.
We'll start with this episode, What is Azure Cosmos DB,
then we'll dive into some use cases,
talk about the concept of consistency
in a distributed database,
and then the last episode of the season we'll cover
hybrid transactional and analytical processing
and synapse link.
So in this episode, let's start from the beginning.
I'll introduce you to Cosmos DB our NoSQL database.
We'll discuss at a high level horizontal scaling,
replication, partitioning, and database schema.
And then we'll dive into some of the data models
that Cosmos DB supports.
So, let's get started.
Applications used to be relatively simple.
We would have an app, an API layer
and a slow drip of data dropping into our database.
Now occasionally, we may have needed to surface that data
and look up device information in a catalog,
or look up an appointment on a calendar.
But often the data sat in the database
until it was called on however many days, months,
or even years later.
In the age of big data, where data sets have now grown
from a few gigabytes to tens of gigabytes and even petabytes
for some of our most demanding applications.
Data is pouring into our databases
and applications are demanding that data be surfaced quickly
and frequently to fulfill user expectations
of a personalized and fast application experience.
Now, Azure Cosmos DB has boomed as the answer
to the big data demands of cloud native applications.
Because non-relational or NoSQL databases
like Azure Cosmos DB scale horizontally
rather than vertically, we can essentially uncap
the throughput and volume of data in our database.
Rather than upgrading hardware on a single node
to serve requests faster, Cosmos DB distributes that work
across multiple node so requests can be served concurrently.
Scaling out verse scaling up is the biggest difference
between relational databases and non-relational databases
like Cosmos DB.
Horizontal scaling or scaling out
is the consequence of two techniques:
partitioning and replication.
Now there are two kinds of partitions in Azure Cosmos DB:
logical and physical.
A physical partition is an actual unit of storage
that physically sits in the Azure region that we dictate.
This is a piece of hardware holding our data
somewhere in the cloud.
Logical partitions are logical groups across items
within our data set, and we reference these groups
through something called a partition key.
The partition key is important
because it tells our database engine
where to look for our data.
Choosing the right partition key
is a simple but important part of optimizing our database,
and when done correctly,
we can expect to see performance gains proportional
to the additional number of nodes serving our requests.
Put simply, partitioning our data across nodes
improves database latency and throughput.
Now like with partitions,
there are also two kinds of replication in Cosmos DB:
replication within a region
and geo-replication outside of a region.
Now within a region, our data is replicated four times
as a redundancy measure, improving fault tolerance.
Outside of a region, our data is geo-replicated
into any additional Azure regions we select
resulting in higher availability.
Replication within a single region
increases fault tolerance.
Geo-replication into additional Azure regions
increases availability.
Now these two techniques, replication and partitioning,
are in large part what makes horizontal scaling possible.
Now what makes NoSQL attractive to modern op devs,
performance and availability gains aside,
are the relaxed constraints
around keeping our data relational.
Cosmos DB is schema-less meaning structure is not enforced
on any data entering the database.
Two documents in the same collection
can have completely different structure without any issue.
And as a result, developers can land
structurally variable data into the database
and later build, change or add functionality
as a use for that data evolves.
This combination of flexible schema and horizontal scaling
are what makes NoSQL different.
Cosmos DB makes it easy to ingest
and resurface high volumes of variable data
without compromising on performance or availability.
In addition to flexible schema,
Cosmos also supports multiple data models.
Our team has built Cosmos to be the hub
for all NOSQL data types.
Cosmos has a SQL API with document
and key value support built in.
Documents and key value pairs go hand in hand
in most NoSQL databases because documents
are just key value pairs in which the key is a document ID
and the value is a JSON object that we just call a document.
Now to reap the performance benefits
of a true key value store, with a SQL API,
we can do fast and cost-effective point reads
as long as we know the document ID and partition key
for the item we want to read.
This is a great optimization tool for applications.
The next data model, the graph data model,
is accessible via the Gremlin API,
which uses edges and vertices as well as well as traversal
to model complex systems with many to many relationships.
Think of a graph as a web or a network of nodes.
The API is for Mongo DB and Cassandra respectively,
are created so that developers
familiar with both open-source databases
can work with the tools, SDKs and drivers
that they're already used to.
API for Mongo DB also leverages documents,
and Cassandra API is a wide-column store,
which orients data efficiently in columns instead of rows
to optimize for analytics.
That's it for our first episode.
Cosmos DB is our horizontally scaling, NoSQL database.
Partitioning makes it fast, replication makes it available
and flexible schema makes it simple to work with.
Thanks for joining us, and tune into our next episode
on use cases to see some examples of how Cosmos DB
is being used in real applications.
(smooth music)