Swiss Army Knife - Azure Cosmos DB

When it comes to storage, we often have to store multiple schemas of data using multiple databases. Due to the need for using multiple services, managing our solution becomes cumbersome and requires a lot of skill to do it in the right fashion. Thanks to Azure Cosmos DB, we can both store records using different database models (such as MongoDB, Table Storage, or Gremlin), and pay only for what we agreed on—throughput, latency, availability, and consistency, all thanks to the serverless model.

The following topics will be covered in this chapter:

• What Azure Cosmos DB is, and how it looks compared to other storage systems
• Partitioning, throughput, and consistency
• Different Azure Cosmos DB database models
• Security features

Technical requirements

To perform the exercises in this chapter, you will need the following:

• Microsoft Visual Studio or Visual Studio Code
• Azure subscription

Understanding Cosmos DB

When working with storage, you have probably heard about different kinds; relational databases, NoSQL databases, graph databases, document databases. There are plenty of different models available, with different characteristics, when it comes to storing data. If you need to easily maintain relationships between tables, in most cases you will choose something such as SQL Server. On the other hand, maybe you would like to save each record in the JSON file format, where the best solution would be an instance of MongoDB. While the choice is all yours, the biggest problem is that you need to have a different kind of service to serve the same purpose—storing data. This is where Azure Cosmos DB comes into play. With its multi-model capabilities, flexibility, and scalability it is a great choice for globally distributed and highly responsive applications...

Partitioning, throughput, and consistency

Now we have learned something about Azure Cosmos DB—how it works and its most common features—we can focus a little bit on three really important topics in this service; partitioning, throughput, and consistency. Those factors are crucial when selecting a database engine to power your application. They directly tell you how it will be performing, how many requests it will be able to handle, and what guarantees apply when it comes to your data integrity.

Partitions in Azure Cosmos DB

Partitioning is directly connected with scaling in Azure Cosmos DB as it allows for load-balancing incoming requests. In fact, there are two different types of partition in this service:

...

CosmosDB data models and APIs

As mentioned earlier, Azure Cosmos DB offers five different database models, all sharing the same infrastructure and concepts. This is a great feature, that makes this service really flexible and able to serve multiple different purposes. In this section, I will briefly describe each database model, so you will be able to select one that best serves your purposes.

SQL

If you think about SQL, you probably see a relational database with tables, relations, and stored procedures. When working with SQL API in Cosmos DB, in fact you will work with documents that can be queried using the SQL syntax. Let us assume you want to query documents using the following call:

SELECT * FROM dbo.Order O WHERE...

Different features of CosmosDB

Azure Cosmos DB has multiple different features that can be used to lower your bills, secure an instance, or integrate with other services. In this section, we will quickly take a look at most of them, so you will fully understand the basics of this service and will be able to progress on your own.

Account level throughput

Instead of defining throughput per each collection, sometimes you would like to set a fixed value for the whole account. This is a great addition if you have many different containers and instead of paying for each individually (as you remember—it was over $20 per month), you can go to Account level throughput and set a throughput for the whole account:

The only...

Summary

In this chapter, you have learned about another serverless Azure component named Azure Cosmos DB. You saw multiple database models that this service supports, and also multiple different features, such as geo-redundancy and the ability to easily scale up and introduce new read regions, where data will be replicated. What is more, you are now aware of multiple consistency models and how to change them in the Azure portal.

In the next chapter, you will learn about another hot topic: reactive architecture with Azure Event Grid.

Questions

1. Which APIs does Azure Cosmos DB support currently?
2. Are there any differences between the capabilities of Azure Table Storage and Table API in Cosmos DB?
3. What are the available consistency models?
4. Which consistency model is more consistent—bounded, staleness, or eventual?
5. Is it possible to restrict access to Azure Cosmos DB to only a single IP?
6. Is SQL API the same as SQL Server?
7. What is the reason for using stored procedures?
8. Is it possible to provision throughput in Azure Cosmos DB for the whole account instead of per collection?

Further reading

• Partitioning data in Azure Cosmos DB: https://docs.microsoft.com/en-us/azure/cosmos-db/partition-data
• Capacity planner: https://www.documentdb.com/capacityplanner
• Azure Cosmos DB RUs: https://docs.microsoft.com/en-us/azure/cosmos-db/request-units
• Consistency levels: https://docs.microsoft.com/en-us/azure/cosmos-db/consistency-levels
• Mongo DB support: https://docs.microsoft.com/en-us/azure/cosmos-db/mongodb-feature-support#mongodb-protocol-support
• Graph API and Gremlin: http://tinkerpop.apache.org/docs/current/reference/#intro