Book Image

Guide to NoSQL with Azure Cosmos DB

By : Gaston C. Hillar, Daron Yöndem
Book Image

Guide to NoSQL with Azure Cosmos DB

By: Gaston C. Hillar, Daron Yöndem

Overview of this book

Cosmos DB is a NoSQL database service included in Azure that is continuously adding new features and has quickly become one of the most innovative services found in Azure, targeting mission-critical applications at a global scale. This book starts off by showing you the main features of Cosmos DB, their supported NoSQL data models and the foundations of its scalable and distributed architecture. You will learn to work with the latest available tools that simplify your tasks with Cosmos DB and reduce development costs, such as the Data Explorer in the Azure portal, Microsoft Azure Storage Explorer, and the Cosmos DB Emulator. Next, move on to working with databases and document collections. We will use the tools to run schema agnostic queries against collections with the Cosmos DB SQL dialect and understand their results. Then, we will create a first version of an application that uses the latest .NET Core SDK to interact with Cosmos DB. Next, we will create a second version of the application that will take advantage of important features that the combination of C# and the .NET Core SDK provides, such as POCOs and LINQ queries. By the end of the book, you will be able to build an application that works with a Cosmos DB NoSQL document database with C#, the .NET Core SDK, LINQ, and JSON.
Table of Contents (13 chapters)
Title Page
Packt Upsell
Contributors
Preface
Index

Checking the request units spent by a query


Every query we execute consumes request units. We can easily check the request charges for a query by clicking on the Query Information tab. The following screenshot shows the information provided by this tab for the previously executed query:

The value for the Request Charge metric specifies the request units that we were charged by Cosmos DB for the executed query. In this case, the query spent 2.35 request units from the request units we are provisioned for the VideoGames1 collection. Remember that we configured the settings for this collection to provide a throughput of 1,000 request units per second. Hence, after we execute this query, we will have 1,000 - 2.35 = 997.65 request units remaining after they are reset to 1,000 in the next second. In an application, we would be able to run this query 425 times in one second with the provisioned 1,000 request units per second. We would have to wait until the next second to run this query again in...