In the previous article ‘Creating collections and Documents in Cosmos DB’, we saw how we can create documents with the JSON data and how we can create it later. Referring to Cosmos DB as multi-model actually means that how you want to obtain your data in the results and that’s when you chose one data model over another. To choose different data models, we select any of the multiple available APIs. Here the job is for the developer to decide as to what type of data it is that is being processed and how should it be presented be it, in graph, table, document or columnar form.
However, one very important thing to keep note of, here is that Cosmos DB uses ARS (Atom record sequence) to store the data and choosing any of the data models doesn’t play any role here.
The different data models that Cosmos DB provides to work with are:
- Document data model that uses SQL API for JSON documents or MongoDB API which works with BSON documents, i.e. JSON documents with support for binary input as well. The MongoDB API also extends wire level support which makes it easier for MongoDB developers to expand their area of work and enjoy the performance with Cosmos DB.
- Graph data models using the Gremlin API which provides a traversal language that helps build a relationship between the data and have access to more data with the help of those relationship among the data.
- Columnar data models using the Cassandra API where in we define the schema and the data is set into the form of columns
- Key-value Data model which uses Table API wherein all the entities can have a different set of key-value pairs. The major use of Table API is that any of our data on the Azure Table Storage can be easily migrated on to Cosmos DB and can be worked well on.
However, which so ever API we choose, it hardly matters apart from the presentation of the data and they simply project our data in different data models. The data is simply stored under ARS. All of the data is actually present in the form of keys and values. Key and value pair is what Table API supports, but actually if we look at it technically, it all the relationship between these keys and values pairs. even for the graph and columnar data models, the data is actually having a key and a value for the key which is just projected differently! This is what ARS actually means, a layer for working with the key value pairs.
If we look at the graph data model which has vertices and edges, they are actually a pairs of keys and values only. Similarly, in the columnar data model, the columns containing the data are just the keys and values
Another added functionality is that within a database that we have created for one project and choosing one API, we are actually allowed to switch to different APIs that makes the whole work a lot easier. Suppose the project has been worked on using the SQL API, but then you want it to be projected in the graph data model, in that case, you will be able to switch to the Gremlin API and looks at the modified results.
Leave a Reply