Azure DocumentDB Database as a Service - Part 1

The best part is, as a part of Azure Document DB, it integrates Azure Search and other Azure solutions that simplifies modern application development.


Figure 3: Microsoft Azure DocumentDB

At this point in this article we get a little about Document DB.

Before jumping into a deep level let's take some basic question at this point as in the following.


Figure 4: NoSQL

What are the factors we choose a specific database?

The very first and most important factor is what the nature of the data is.

If the data has a simple tabular structure, like an accounting spreadsheet, then the relational model could be adequate.

But if the application is dealing with the data such as geo-spatial, such as engineering parts then that tends to be very complex. Data may have multiple levels of nesting and the complete data model can be complicated and complex. Before No SQL such data has been modelled into relational tables only, but has not fit into that two-dimensional row-column structure naturally.

Applications these days are dealing with complex data that may involve Multi-level nesting and hierarchies. This kind of data is very easily represented in the JavaScript Object Notation (JSON) format.
As a database grows in size or the number of users multiplies or the structure involved multiplies the nesting levels, many RDBMS-based sites suffer serious performance issues. No SQL playes a very important role here.

NoSQL

A NoSQL (often interpreted as Not only SQL) database provides a mechanism for storage and retrieval of data that is modelled in a manner other than the tabular relations used in relational databases.
The motivation that was behind NoSQL is simplicity of design, better horizontal scaling and finer control over availability.

The data structures used by NoSQL databases (for example key-value, graph, or document) differ slightly from those used by default in relational databases, making some operations faster in NoSQL and others faster in relational databases.

One more key factor that make No SQL different and unique is that it is independent from the Structured Query Language whereas relational databases are dependent on it.

NoSQL databases are designed to excel in speed and volume. To pull this off, NoSQL software will use techniques that can scare the crap out of relational database users, such as not promising that all the data is consistent within a system all of the time.

The growth of Big Data is also one of the reasons for adopting NoSQL.

The nearly limitless array of data collection technologies ranging from simple online actions to Point Of Sale systems to GPS tools to smartphones and tablets to sophisticated sensors, and many more, act as force multipliers for data growth.

The following are some basic requirements and expectations in the case of Big data.

1. High data velocity: lots of data coming in very quickly, possibly from multiple locations.
2. Data variety: storage of data that is structured, semi-structured and unstructured.
3. Data volume: data that involves many terabytes or petabytes in size.
4. Data complexity: data that is stored and managed in multiple locations or data centres.

DocumentDB is a highly scalable, NoSQL document database service offering rich query and transactional processing over a schema-free JSON data model.

The service helps us to quickly build, grow and scale applications that run in the cloud when predictable throughput, low latency and flexible queries are key.

Azure DocumentDB is a NoSQL document database service designed from the ground up to natively support JSON and JavaScript directly inside the database engine. It is the right solution for applications that run in the cloud when predictable throughput, low latency and flexible query are key.

If we talk about the differences between Document DB and relational databases, in a relational database system we must define a schema definition before adding records to a database tables. The schema is the structure described in a formal language supported by the database and provides a Blueprint for the tables in a database and the relationships among tables of data.

Apart from that we also need to define many constraints in the database table in terms of rows, columns and last but not the least data type of each and every column.

Whereas in the case of the document-oriented model, data objects are stored as documents.

Each document stores your data and enables you to update the data or delete it. In this case instead of columns with names and data types, we describe the data in the document and provide the value for that description. If we wanted to add attributes in a relational model, we would need to modify the database schema to include the additional columns and their data types. Whereas in the case of document-based data, we would add additional key-value pairs into our documents to represent the new fields.

In the next part we will have a look into what the capabilities and benefits of Azure DocumentDBs are.