Cost of using Cosmos DB

The cost of using Cosmos DB. In this section, we’re gonna look at how the charge model in Azure works for Comos DB and how you can keep an eye on that actually working as well. Cosmos works, in terms of the cost model, using something called resource units.

You can see from the data explorer that we have on the screen here, where we just look at the same local one at the moment. In these scale and settings, you have this throughput. And that marks as the resource units per second.

And this is the maximum amount of throughput and processing using the process of the memory that your instance of Cosmos will be able to handle. And you can change that. You can very easily move up and down.

If we’re gonna look at the Azure portal, exactly the same detail there. You can see from the portal.Azure.com , we’ve got 400. The only thing is it also tells you how much you’re looking at charging. So that’s for a single region, 400 RUs. You’e looking at around $0.032 hourly.

If you want to know how much you’re using of that, then you can start to look from the analytics. You’ve got the number of requests. And you can see that usage outlet. So you can get a very up to date view of your billing that’s taking place. So you can look at the storage and the throughputs of those items.

Also when you’re running queries, if we just execute this query now, that was just accounts there of the locations. You can see what the charge is for that query. So when I run that query, it was 3.16 resource units per second just for that count, which means if I’ve got 400 RUs, I can run 100 times that and still have a little bit of capacity.

You’ve got some other details going through, such as how long it took and other items. And that will run for any one of these;

If we take a look instead at the joint there, you can see that’s 3.27 RUs. So again, not a very big item. And it will take into account how many documents retrieved, how many documents in total there are, all these items.

Could I give you a calculation for what an RU will be up front? No, I would highly recommend running your query and taking a look at it.

So you can see here, we’ve got accounts. If we bring back all items, suddenly that count of the larger amounts of location objects is a higher RU because there are more location objects. And even though it’s because it’s partitioned, it’s bringing back that more effectively. But because there’s a lot more being returned, it will use a higher amount of RUs.

If I add a bit more to that query and as well as location, possibly add some sub filters to it. Let’s think about country maybe or county, in fact, not country. And just bring back the New York ones. So NY.

So smaller subsection, and you can see slightly lower stats there, but not much because a lot of it is around. So if we look at that 13.15 to 13.98, it is a lot about the total volume of things in the filtering you’re doing within that will have the bigger impact on these items. And it’s worth playing around with the different details as you review this for your data.

Now, it will automatically index all your data. So you don’t need to worry about indexing. But it’s worth looking at your queries and how you apply your partitioning.

As you work with your code, it’s worthwhile looking at the different things like the get items, especially with those queries, running through those queries, and understanding how many resource units you think you’ll be taking and thinking about filtering and applying those partitions to only bring about the data you need. Now, one of the big reasons, if we jump back is you will get your scale in settings. You can very easily increase that. But it will be at a cost.

So in this case, you’ll run your local emulator. We can bump the number up whenever we want and just click Save straightaway. And you can do that in Azure as well. But then there’s the cost. And you’ll start to see the requests going.

Now, if we’ve set out to 400, you’ll see the number of requests and resource units there. You’ll be able to see that cap out. And you get some monitoring there. But the big details are here in the metrics. So you can see how much of your index data is being consumed, how much of the data, and how big the index is.

And importantly, the number of requests that exceed that capacity. So if you do exceed, you will start getting responses back from the REST interface. The SDK will handle that and will just keep retrying. So you don’t need to build anything into your code. But you will start to see peaks in these items. You will start to see it leveling off. And that’s a good indicator either you need to review your queries and your partitioning, or you need to increase the amount you’re using.

You can also go back and get more detail because you may not be able to see everything here. You can use the diagnostic logs to push into Azure storage or into other feeds where you can go and see each of the queries that are being run. And you can actually get the number of resource units that are being run for each of those queries. So in this case, I’m just putting it into another storage account in my tenancy. And it will push those data out.

They’re not the easiest logs to use. And I’ll certainly push it into the event hub to get better querying on that. But it gives you that visibility into how your details can run, something which will be looked at in a future video as to exactly how you can dig down into getting your queries out.