CosmosDB pricing model

The fundamental pricing unit in cosmos is called Request Unit. The RequestUnit is a measure of throughput and it is an abstraction over compute, memory and IOPS required to serve a request. The idea with the model is that number of request units required for an operation is deterministic so a query will always cost the same. The cost of every operation is returned back to the client via the SDK or response headers so you can always track and manage your cost.

So, what happens if you’re trying to use more than you have provisioned? Every time you issue a request that would consume more resources than available, Cosmos will reject the call and return details about how long you should wait before issuing the query again for best chance of execution.
If you’re using the Cosmos SDK you are going to benefit from a built-in automatic retry policy that will try and seamlessly rerun your query according to the timeouts recommended in Cosmos. If Cosmos still can’t fulfill the request, the SDK will eventually give up (default policy is to retry 5 times) and you will get an “Request rate too large” exception that you will need to handle manually.
With this functionality, often times you don’t even have to worry about exceeding the provisioned resources, assuming you are not getting long-running or very high spikes in load.

Read More

Share Comments

CosmosDB REPL console app

There are a few ways you can explore your data in CosmosDB, either via the Azure Portal or with the Azure CosmosDB Graph Explorer - here. However, I wanted a quicker way that I can run queries and check results and performance locally so I created a console app that allows you to do just that.

Read More

Share Comments

CosmosDB Query with Partition

ComsosDB is the first database system that promises <10ms latency on reads at the 99 percentile, and backs it up by an SLA. The way to achieve that performance though is though smart partitioning of your data. Here are a couple of notes that you can use when designing your queries that will definitely help improve performance - especially in an unlimited collection (one with multiple physical partitions)

Read More

Share Comments

CosmosDB with Gremlin.NET - part 2

On top of being faster than the original client, the Gremlin.NET native driver comes with a couple more features that make it really appealing to use: Fluent API and Query Bindings

Read More

Share Comments

CosmosDB Graph using Gremlin.NET

Up until recently, the only way to communicate with the CosmosDB Graph API was though the DocDB Graph Client - Microsoft.Azure.Graph . Like I mentioned in some of my older posts that was not the most optimal implementation.
Luckily we can now use a native Gremlin driver to communicate with the CosmosDB graph database. Gremlin.NET is an open source generic Gremlin driver that can be used to communicate to a CosmosDB Graph account.

Read More

Share Comments

Protecting a web-app with AzureAD

Deploying a web application on azure is incredibly easy these days. You can handle everything, including creating a whole new web app and app service directly from Visual Studio. A lot of times we deploy these small web apps as internal tools for our team or company but we must not forget about securing those behind a log-in so that they are not accessible to anyone trying out domains at azurewebsites.net

Read More

Share Comments

Azure CosmosDB Graph Explorer

Azure CosmosDB Graph Explorer is a great opensource tool that allows you to easily and quickly visualize the data you have in your Azure CosmosDB Graph (yes, just graph at the moment).

Read More

Share Comments

ServiceFabric RemotingTransport settings in ASPNET Core project

When wirting a Service Fabric Service that uses the Remoting Transport layer, you sometimes need to update the default settings to allow for a greater message size or operation timeout.

According to the documentation, this is achieved by overriding the default settings in the Assembly manifest file that you find under Properties/AssemblyInfo.cs

1
2
3
using Microsoft.ServiceFabric.Services.Remoting.FabricTransport;
// Allow messages up to 100 MB, operation timeout to 10m
[assembly: FabricTransportServiceRemotingProvider(MaxMessageSize = 100000000, OperationTimeoutInSeconds = 6000)]

However, you might notice that if you created an ASPNET Core service (to use as a gateway perhaps), the new project type does not have the AssemblyInfo.cs file anymore. Even more, if you create it yourself, it will be ignored.

This is happening because in the new ASPNET CORE project type, the AssemblyInfo file is auto-generated during build. Since there’s no other way (as far as I could find) to update our remoting settings, we need to get rid of the auto-generated file and write our own.

First, create your own AssemblyInfo.cs file under the Properties folder.
Next, find the auto-generated file in the obj folder. Copy its contents over into your newly created file.
Lastly, we need to instruct the build system to not generate the file automatically any more.
We do this by updating the project file:

1
2
3
<PropertyGroup>
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
</PropertyGroup>

That’s it, with these changes, you now have the new remoting settings available for your ASPNET CORE project.

Share Comments

CosmosDB graph formats

When working with CosmosDB GraphAPI it helps to understand how the engine stores or manipulates the inputs, so I will try to explain the data formats.

Read More

Share Comments

Mixing Gremlin with DocDB API in CosmosDB

One of the best things about CosomosDB is the ability to mix and match APIs and models based on what makes sense for your use case.

Sometimes it just makes sense that your database is built as a graph, and in that case you can use the (familiar) Gremlin language to write your queries. However, for some things it might be easier or more optimal to use familiar DocDB APIs.

Read More

Share Comments