Starter for 10: Meet Jonna Iljin, Nordcloud’s Head of Design
When people start working with Nordcloud, they generally comment on 2 things. First, how friendly and knowledgeable everyone is. Second,...
Azure Cosmos DB is a multi-model database service by design, which can be easily globally distributed. Database engine supports storing of data in documents, key-value pairs and even graphs. Scaling of Cosmos DB across any number of available locations is extremally easy – just press the appropriate button in the Azure portal. In modern web-based applications low latency is expected by the end users. With Cosmos DB you can store data closer to application users. Database can be distributed and available in 50+ regions. This creates enormous opportunities. Regions management can be involved at any time in application lifecycle.
Based on the above, global distribution of data with Cosmos DB provides a set of benefits such as:
For development purpose Microsoft provide Azure Cosmos DB emulator. Functionality is close to native cloud version of Cosmos DB. Developer will be able to create and query JSON documents, deal with collections and test stored procedures or triggers on database level. We need to understand that some features are not fully supported locally. These are among others multi-region replication or scalability.
Later in this post I will try to explain more details about supported data models. All of them use main, cool features provided by Azure Cosmos DB.
Existing instances of MongoDB can be migrated to Azure Cosmos DB without huge effort for this activities. Both standards are compatible. If new environment is created, change between native MongoDB instance and Cosmos DB instance (by MongoDB API) comes to change a connection string in application. Existing drivers for application written for MongoDB are fully supported. By design all properties within documents are automatically indexed.
Let’s check, how simple queries for identical documents collection as used in previous point will look like:
As a result, specified sub-JSON contains data will be returned. If query doesn’t return results, empty object will be send as a response to query.
This kind of API can be used by applications prepared natively for close working with Azure Storage tables. Of course Cosmos DB provides some premium capabilities comparing to Storage tables e.g. high availability or global distribution. Migration to new DB source for application doesn’t require changes in code. User can query data in a few ways. Also lot of SDKs are provided by design. Below sample will show how to query data by .NET SDK with LINQ. During execution LINQ query will be translated to ODATA query expression.
Azure Cosmos DB Cassandra API is dedicated data store for applications created for Apache Cassandra. User is able to interact with data via CQL (Cassandra Query Language). In many cases action for changing DB source from Apache Cassandra to Azure Cosmos DB ‘s Cassandra API is just changing a connection string in application. From code perspective integration with Cassandra is realized via dedicated SDK (NuGet -> Install-Package CassandraCSharpDriver). Sample code for connecting to Cassandra cluster from .NET application is presented below.
The last API provided by Azure Cosmos DB (on the day of writing this article 😉) is Gremlin API. This kind of interface can be used for storing and operation on graph data. API supports natively possibilities to graph modeling and traversing. We can query the graphs with millisecond latency and evolve the graph structure and schema in easy way. For querying activities we can use Gremlin or Apache TinkerPop languages. Step by step process from NuGet package installation to run first query is has been shown below.
From the developer perspective, Azure Cosmos DB is very interesting service. Huge range of available APIs allows for using mentioned database in various scenarios. Below you can find information from official Azure Cosmos DB site about availabilities of APIs per programming language.
Source: Azure Cosmos DB Documentation
This post is the last part in our Azure DevOps series. Check out the previous posts:
Let’s discuss how we can help with your cloud journey. Our experts are standing by to talk about your migration, modernisation, development and skills challenges.