NoSQL and SQL Which one to use part 1

Preamble…

For over 2 decades. Relational Databases have held sway. They have reliably stored and served the most critical of data.

Most of the data we needed to store then was structured in nature e.g

user information(name, age, state_of_origin etc) or product information (productid, description, cartegory, quatity_in_stock)

With the advent of the internet and accompanying stuff like IoT, social media etc, some major shifts in data have occurred.
Data now comes in much higher volumes, wide variety and rapid rate.
NoSql evolved to address these issues.

Even though NoSql evolved to adress situations that Sql databses would not be a good fit, one thing to note is that NoSql is not a replacement for Sql(Relational) databases.

Relational(SQL) databases store data in logical structures called tables, so we have rows and columns(fields).

These can be visualized as an excel spreadsheet (note visualize, a spreadsheet is NOT a relational database) with rows and columns.

NoSql storage varies and can be divided into 4 broad categories explained below….

Types of NoSql

There are different categories of NoSql databases. Some of the prominent ones are listed below

Document oriented

these store data as JSON documents e.g Mongodb

Key Value Store

these use a harsh table with a unique key pointing to a data item e.g Redis

Columnar Store

These store large datasets across multiple servers and are designed to be high performance for read and write and for hight availability e.g Hbase

Graph databases

A graph database can be visualized as a tree with branches that branch off of branches that branch off of branches …(you get the idea) e.g Neo4J
This serves as an introduction to the topic.
My next post will explore the reasons to choose an Sql database or a NoSql. We will also look at reasons to choose a particular type of NoSql based on the situation.