Azure CosmosDB DP-420 Prep

What is Azure CosmosDB? It’s a NoSQL Database offering that offers scale massively across practically unlimited partitions.

How does this intersect in the data domain? Likely after you’ve complete DP-900 you’d want to scratch the surface of understanding more how data interacts in the cloud and perhaps use cases that your organization is evaluating.

CosmosDB offers two options Provisioned Throughput / Serverless, now consider the use cases between traffic on these as you’ll clearly have purpose to use Serverless in databases that don’t have write/read operations heavy that is needed.

CosmosDB offers a free-tier to utilize and a emulator as well so don’t worry about not being able to utilize this service with high costs of entry.

For this I’m going to show what is needed to deploy and do this via CLI with a diagram to describe what’s happening.

az group create -l westus -n CosmosDBProd-WR --tags "devops"

So now that we have our resource group “CosmosDBProd-WR” cloud basics should cover the naming conventions that are easy for your users/engineers to access and know which workloads are classified/categorized (another discussion that we won’t cover)

So I’m here in the Azure Portal and I’m going to click Azure Cosmos DB

We’ll click create and go through the UI for familiarity on options and configurations

We will use the Core SQL API

I highlight this portion of the configuration because you’d want to keep this resource restricted or behind what we call a “private endpoint” like anything differences in development and production just to show you these options for this I’m staying all networks to show you how I’m going to connect.

So we just deployed a CosmosDB Account via the Portal and put this as Serverless.

You have a few things to consider after this such as is this going to be accessed what controls are going to place this in a more secure manner but also delivering scale of delivery? Consistently consider how the services you are deploying in cloud and how they are secure.

After we have our resource group deployed now we can deploy our Azure Cosmos DB service via CLI

az cosmosdb sql database create --account-name west-prod1
                                --name west-db-prod
                                --resource-group CosmosDBProd-WR

So let’s breakdown this syntax to help you out on what we just did, so we’ve called CosmosDB SQL API via the CLI with a few parameters such as –account-name area to name it west-prod1 to notate the location and purpose. Next we’ve declared that the database name will be called “west-db-prod” and a partition key that is /id, you have to determine a key partition based on your workload. You want this to be unique in nature but that can hold data to help you identify quickly what information you’re going to use this database for. Think of this every time you are making a SQL query you’re charged by what is called Request Units, this is essentially the compute costs of that query and depending on how the query is composed can vary in charge. We’ve put that we want this in our resource group we’ve created previously.

After the CLI completes successfully can see the database we’ve created programmatically, not to bad right? Practicing your CLI will make you more confident but also break down actions and help you not rely on the portal.
So now after the DB we will create a container this is shown via the portal

If you wanted to run some analytics that is what the “Analytical Store” option is, this will allow you to use the power of Azure Synapse by creating another column to capture OLAP data that can be used to analyze at a later time.

As you can see this is in JSON format I’ve added just an example thinking of logistics that would be included along with the warehouse

So every addition into our contianer will have these values shown below query these are unique and generated at each creation.

Okay you’ve gotten this far whats next?

Bring data into CosmosDB via Azure Data Factory/Data Migrate we will cover this in another post a few items I’ll show on the configuration to consider.

Default Consistency can be change say as your database grows with more containers to sort or a influx of data is starting to pick up from a time of year (holidays).

This is covered in DP-420 Objectives so you should familiarize yourself with the difference and think of how would these apply to your use case.

Session as shown below

Okay that’s our overview of Azure CosmosDB the creation of it and using Data Explorer, Default Consistency.

In the follow up post we will explore Azure Data Factory and others stay tuned.