Types of NoSQL Databases

 

NoSQL Databases are a new form of database that is gaining popularity and are increasingly used daily. Most of the companies are switching to these databases due to the wide variety of their use cases. A famous one that we always keep hearing is the "MongoDB". 

But what in actually is NoSQL,  NoSQL term was coined and founded in the 21st century only with the rise in Web2.0(the current face of the internet), due to the increase in unstructured and Big data (Eg. Tweets generated from Twitter, images and videos shared on social media, logs generated by sites, purchase history of a customer etc.)  that was not feasible for the traditional SQL databases to store and process. Thus, NoSQL can be defined as the SQL for the Unstructured and Big data.

Still unable to differentiate between SQL and NoSQL..!!! Read it here. 

How Data is stored in NoSQL Databases? 

So, now coming to the point, when the data generation sources are so different and in various formats then how the data is stored in NoSQL databases. 

Unlike traditional SQL databases, we are not compelled here to format our data in tabular format, i.e. rows and columns rather we are privileged enough to store the data in whatever format we get from the source, i.e text, linked data of purchase history etc. To be more precise we can say, NoSQL provide us with 4 different data formats in which we can save our data. 

The 4 different formats are:- 

1. Document databases
2. Key-value stores
3. Column-oriented databases
4. Graph databases

Document Databases

One of the most common and widely used data is documents, not any typical word document but semi-structured data formats like JSON, XML, YAML and binary forms like BSON. Storing data in these formats is quite useful as the data is already stored in the semi-structured formats thus it gives flexibility to directly fetch the data from the database and use it in our application without any formating. 

Take an example of a simple web application where data is stored in standard SQL databases, for display on the UI when the data is retrieved from the SQL database it had to be formatted to XML or JSON format, which is then used for rendering the WebUI. At the time of saving the data, a reverse process is followed where data from UI is collected, unformatted and then saved back to the database, wasting a lot of time and memory in formatting and unformatting. Also, these could be easily read and understood, making it a more preferred option for saving our data.

Thus, it becomes quite easy to use and the preferred choice for most developers as it provides flexibility to change or modify the existing document structure based on the changes in the requirement.

Few use cases, where the document database is/can be widely used, are Web App, e-commerce platforms etc.

Let's see an example of the document database to understand it better.

Document Database

The above images show a rough diagram of the documents database, where data is written in some semi-structured format on a file and then it is stored in the database. 

Key-Value Store

Key-Value stores are the simplest form of data used for non-relational databases. As the name suggests data is stored in Map or Dictionary data model, i.e. the data is represented as key-value pair, such that each key is represented only once per data model. 

The best example for the key-value store is the HashMap in java or the dictionary in Python. Since the format can be directly saved and used in the code, it becomes straightforward for the developers to use it as it can be treated as the part of the code only rather than any separate data model, which needs to be modelled and remodelled again and again throughout the code for use. Thus, providing Speed and  Scalability together with Simplicity.

Few use cases where the key-value store is/can be used are user profiles, preferences, shopping carts etc. 

Let's see an example of the Key-Value Store to understand it better.

Key-Value Store

From the above image, it can be seen that the data here is broken in the key-value pair and stored. A simple example of a key value can be shown below:- 

Site:- Quick Data Science

Email:- quickdatascienceds@gmail.com

Instagram:-  https://instagram.com/quickdatascience?igshid=YmMyMTA2M2Y=

Telegram:- https://t.me/quickdatascience

Youtube:- https://youtube.com/channel/UCebjPNZW0JX1BTkbz5DVMuQ

Where Blue ones are the Keys and Green ones are the Values.

Column-Oriented Databases

Column-Oriented Databases are not so typical databases but were derived from the basic Row-Oriented databases used in relational databases. Row-Oriented databases are the typical table structured format for data storage in SQL databases, but they suffer from a less known but severe problem. 

In Row-Oriented databases, mostly the data is stored for the columns that are mandatory and for whom the value is provided. There might be a variety of columns that are not very much of use for us(the dev team)., but still needs to be stored and whenever a data search is run in the table it scans the whole table, i.e. the unwanted columns are also scanned. This not only increases the data retrieval time but also adds an extra load at every level. 

To overcome this issue, column-oriented databases were created, where the data is stored in columns only instead of rows more precisely a single column table with each row indexed and data for each column is stored separately with proper linking. Doing so makes it easy to retrieve the data, i.e. we can simply read the data for the column we are interested in and not the whole table.

Let's see an example of the Column Database to understand it better.

Column Database

In the above image, we can notice that the data which was usually stored in the table format in a standard SQL database is divided here, and the data from each column is stored here in separate table type structures with IDs. 

Graph Databases

One of the most complicated and rapidly growing database types in NoSQL is Graph Database.

A graph database can be thought of as the things/entities as the nodes and the relation between them as the lines joining them. Thus, a graph is made up of two main components Node and Links. 

Node:- the entity or the object that is the centre of our application. 

Links:- the relationships between two entities. A line joins the two nodes based on some relation. 

Let's see an example of the graph database to understand it better.

Graph Database

In the above image, we can see there are 3 people, some sports, cars, an office, and a book all these nodes are connected to one another in some way or another like Person 1 & Person 3 plays a common sports, Person 1 & Person 2 drives the same brand and model car as well as they both are friends. Similarly, Person 2 & 3 works at the same company. 

Thus, graphs are an easy way to collectively represent a lot of data(nodes and links) together, which is increasing day by day with the increase in online activities. The same mail ID is used to log in to social media, games, e-shops, official documents etc. thus, providing a link between all the sites and user activity related to that particular user. Thus, storing all these data in a graph database is a better option than any other database. 

Tables in NoSQL

Unlike SQL/Relational databases, here in NoSQL or Non-Relational databases, different databases are used for different kinds of data. This is because all the different types of formats used in NoSQL are different and no one data can be used for storing or processing all the types. 

Let's have a look at the different tables that are used for NoSQL. 

Relational & Non-Relational Databases

A combined list of a few databases that can be or are widely used for different data formats for storage is shown above.