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.
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)
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.
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
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:
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.
One of the interesting things that caught my eye in the newly released 0.3.0-preview SDK was the .limit() step optimization. Like we saw in one of my older posts, limit() was executed client side, so you’d get the entire result set from the server and the client side sdk would filter and return it back to caller.