WHY NOSQL- PART 2 — OVERVIEW OF DATA MODEL,RELATIONAL & NOSQL
By: Ananth Packkildurai
Tags: Cassandra, Column Database, Couchdb, Document Database, Graph Database

This is part 2 of Why NoSQL series. You can view the first part here. In this post we will have an overview about various data model been which upon NoSQL databases been build and compare it with RDBMS data model.

All through the post we can examine different data model with famous employee data. Typically in an office employee will have following records,

empid

emp_name

department

designation

and consider the company has different department.

Let us examine the relational database model first.

Relational Database model:

Relational database model first been proposed by Edgar F. Codd in late 1969. The fundamental assumption of the relational data model is that the data is represented as a mathematical n-ary relation which is a subset of Cartesian product. The data been accessed by means of relational algebra using set theory and the consistency been achieved by applying constraints like primary and foreign keys.

So the typical data model for employee problem will be,

NoSQL data model:

The NoSQL databases taken a completed different approach and implements day-to-day data structure based solutions. There are different types of data models been implemented.

1. Column Families or wide column store

2. Document Store

3. Key/ value Store

4. Graph Data store

1. Column Families or wide column store

Examples: Cassandra, HBase

Typical usages : Distributed data storage.

The column families basically extends the typical key/value pair storage and provide two level of nesting. The nested key/value pair is called column in column family storage. Each column can be grouped with a key and thus provide super column functionality as well. The typical use case will be the application with extensive read/write operation. Facebook messenger uses Hbase. Typically the employee data model will look like below,

2. Document Store

Examples: CouchDB, MongoDB

Typical usages : Web applications.

Document based data model used to store and retrieve document oriented or semi-structured information which is common on web-based applications. Typically all the modern document based data models follow the XML,JSON or BSON model that is easy map with the data model. It is also enable APIs easily interact with the databases as most of the modern-day languages support these formats in build. The data model of Employee will look like,

Id = “001”,FirstName=”Ananth”, LastName=”Durai”, Department=[{Id:”DIT”,DeptName:”IT”}],Designation=[{Desig=”Software Programmer”, Salary:0}]

3. Key/ Value store

Examples: Membase, Redis

Typical usages : Distributed Hash table, caching

Key / value store function as typical Hash table where it will store the value against a key. This will enable to create schema less storage. It will be best in use when we have excess read operation than write operation. Say for example we have to display Latest post on forum on every 2 minutes, It makes sense to run a background job on every 2 minutes and store as key value pair and read data from there. Lot of content intensive websites using in memory key / value pair storage system.

4. Graph Databases

Examples: Neo4J, InfoGrid

Typical usages: Social networking, Recommendations

Graph data model typically follows the Graph algorithm to store data with nodes and edges. Graph databases are best suit where we face recursive data model. Each an every node will have the following attributes

Node

Property

Relationship (Edges)

We can map it to the our Employee object.

Here

Node : Employee

Property: first name, last name, designation and department

Relationship : Employee part of a department

We can see more like eventual consistency and best use cases on the next series.