NoSQL and SQL Which one to use part 1

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.

Storage

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 and 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.