As part of their cloud offerings, all major providers (Microsoft, Amazon, Google) have developed very exciting and interesting NoSQL/NewSQL offerings. Microsoft Azure’s is called Cosmos DB, a rebranding of the product initially known as DocumentDB.
Cosmos DB is no longer just a JSON document database, but also includes APIs for Key-Value storage, Graph and Wide-Column is on the way. Being a Database as a Service product, you don’t have to worry about the underlying hardware or operating system, Microsoft manages all this for you. Because we are abstracted away from hardware details, the resources needed for our database are defined by something called “Request Units”.
What is a Request Unit?
A request unit is a unit of throughput and the amount consumed will depend on the operation performed. Reads consume less units than writes. Stronger consistency models consume more request units than weaker consistency models.
The amount of request units consumed by an operation is deterministic. So, if your database is not changing, the same query will always cost the same amount of units. At the same time, if your dataset continues to grow and the query requires more compute power, your units consumption will grow appropriately.
While this might seem complicated to people that are used to capacity planning their databases based on cores, RAM and IO, it actually simplifies the process of forecasting your needs. You only need to keep track of one measure, the units and can trend it over time. Resizing units is also a very fast operation in Cosmos DB which means that you can scale up or down very quickly if necessary.
How to calculate your Request Units?
To get an initial estimation of what value to use for your request units, Microsoft has created an online calculator HERE. You can upload a sample JSON document to the site and provide an estimate of how many operations you will be doing per second. The website will then give you a Request Units estimate and projected cost. Keep in mind that the site does not give you a way to estimate queries, only reads. This means that the estimate is likely to be on the low end if you are going to be doing SQL queries.
In any case, you can use the estimate value from the calculator and then tweak it up or down with some testing. Fortunately, Cosmos DB resizes very fast so it’s not a big deal to adjust the request units.
How to get the best performance?
The key to getting the best performance on Cosmos DB is similar to any other database system: know your workload well. If you analyze and understand your workload then you have several configuration knobs that you can play with to get the best performance out of the system. For example:
- What is the weakest consistency model that your application can use and still be OK?
- Can you tune the indexing policy so you’re not indexing fields that are never used by queries?
- Would the application be OK with lazy indexing as opposed to consistent indexing?
- Is your collection partitioned on an appropriate key that minimizes hot spots?
If you dig into your requirements and learn what trade-offs are acceptable, you can tweak the configurations to the point where you can easily cut your request unit consumption in half or more.
Future Direction
In terms of request units there are a couple of current weaknesses:
- Units are charged per hour. So on each hour you will be charged based on the highest units amount you requested. This makes scaling down not as effective cost-wise unless you do it right at the end of the hour (so the next hour starts at the bottom value).
- There is no auto-scaling capability built into the system. You could implement this on your own with the Azure metrics API and a reactive Azure function that would respond to throttle errors. However, it would be even nicer if the platform did it.
I hope in the future Microsoft will address these two items, however I don’t see them as major show stoppers for getting a lot of value out of the service.
Demo Time!
Alright, less talking and more showing! In the video below you can see how RUs get depleted on a Cosmos DB collection, how soon a scale operation completes and how it impacts our application. Enjoy and thanks for watching!
No comments