Be non relational… No SQL

Introduction

The term NoSQL was coined by Carlo Strozzi in the year 1998. He used this term to name his open source, light weight, the database which did not have an SQL interface.

In early 2009, in  an event on open-source, distributed databases, Eric Evans, a Rackspace employee, reused the term to refer databases which are non-relational.

What is NoSQL?

NoSQL is a non-relational database management systems

•It  does not conform to atomicity, consistency, isolation, durability – four obvious features of traditional relational database systems.

•It is designed for distributed data stores where a very large scale of data storing needs (for example Google or Facebook which collects terabits of data every day for their users).

•These type of data storing may not require fixed schema, avoid join operations and typically should scale horizontally.

Why NoSQL?

•Big data:

When it comes to handling big data — a huge number of read-write cycles, a massive amount of users, and data in petabytes, NoSQL databases can do it easily.

•Schema-less:

Most NoSQL databases are schema-less and very flexible. They provide many choices when it comes to constructing a schema, and hence objects can easily be mapped into them. You can get rid of techniques like normalisation and complex joins!

•Programmer-friendly:

These databases have an advantage that they provide simple APIs in every major programming language, avoiding the need for complex ORM frameworks. Even if it isn’t available in a particular programming language, data can easily be accessed over HTTP via a simple RESTful API, using XML or JSON.

•Availability:

Since most NoSQL databases are distributed, they provide easy replication of data, and failure of one node does not affect the availability of data — it only becomes a minor hindrance in terms of performance.

•Highly scalable:

This is the major reason these databases are all the rage these days because they do not require a dedicated high-performance database server. In fact, they can easily be run on a cluster of commodity hardware; scaling out is just a matter of adding a new node.

•Low latency:

The latency of the order of a few milliseconds can be achieved using these databases, although it also depends on the amount of data that can be loaded into memory. However, since we might mostly be dealing with a cluster of data servers, memory would not be a problem.