– Sonu Oommen 

Alice: Hey! I heard that you on a new Project in which they are going to use a different database?
Bob: Yes, they are gonna use NoSQL for that project.

Alice: What is it… No Structured Query Language..eh?.
Bob: Oh no they call it “Not only SQL” actually.

Alice: Great ! That explains a lot, what exactly is NoSQL ?, I mean this must be some anti SQL movements, don’t you think the name makes it kinda obvious.
Bob: No, NoSQL was initially nothing but a catchy twitter hash tag, with the purpose of attracting people for a meet up, #NoSQL, just like red black tree, which got its name because the guy who invented it had just two inks to distinguish 2 types of node “red” and “black” and Voila! the name just “happened”.
Alice: How different is it from the traditional table databases ?
Bob: Well, to start with there are no table and most data models in NoSQL are not relational. They store data as a whole like an object, unlike RDBMS in which we rip of data from the object and store it in different tables.
Alice: Data as a whole object, but that makes no sense.
Bob: Yeah it doesn’t if you think of it from a RDBMS point of view. Think of this as your assignment notebook. Your note is the database and assignments are the collection containing all your assignments. Then each assignment is an object and while storing it we store it as a whole without breaking it down.

##collection
Assignments:

##object 1
Assignment 1:

#object 2
Assignment 2:
.
.
.

Alice: Well don’t you this would lead to a lot of data and redundancy ?
Bob: Yes, but we don’t have to worry about that. Today’s databases are not costly as they used to be and moreover today data is more valuable than the storage cost.

Alice: And what exactly does data models in NoSQL mean ?
Bob: Well this is what I found “A data model is a conceptual representation of the data structures that are required by a database.
The data structures include the data objects, the associations between data
Objects, and the rules which govern operations on the objects. As the name implies, the data model focuses on what data is required and how it should be organized.”
They are 4 data models in NoSQL
1. Key-Value Pair
2. Document Type
3. Column-Family type
4. Graph

Alice: Can you speak in English ?
Bob: Ok let’s take it one at a time:
Key-Value Pair-
It’s basically like a big hash table, wherein we have a key and corresponding to that key we have some value stored. For example:
Take our example of Assignments
Here Assignment1 is a “Key” and its corresponding data is the “value”.

Alice: hmm…
Bob: Ok here is a better one, let’s say we want to store Ruby on Rails Pvt. Ltd. address in US and India

Key
 
Value
 
“India”
 
{"Ruby Software Resources, 
 3740 DaVinci Court
 Suite 300
 Norcross GA, 30092, 
 Phone: +1 770-325-4352, 
 Fax: 770-234-6195, 
 Email: contact@ruby-software.com"}
 
“USA”
 
{"Pamba Building
 Trivandrum Technopark,
 Kerala, India -695581,
 Phone: +91 9446472021,
 Email: contact@ruby-software.com"}

Alice: Oh okay, I got it, you don’t store state and country at a different location like we do in RDBMS to prevent redundancy. So we only need to get the key and we can have all the data without having to define any relation. I see we don’t have any schema here, so NoSQL is schema less and unstructured ?
Bob: Mostly, yes. But let me introduce you to the Document Type first. This is almost like Key-Value pair, the difference being that it is kinda semi-structured. for eg:
If we were to store the address data in Document data type it would look like this

{office : “Ruby on Rails Pvt Ltd”,
location : “USA”,
Address : “3740 DaVinci Court Suite 300
Norcross GA, 30092”,
Phone: “+1 770-325-4352”,
Fax: “770-234-6195”,
Email: “contact@ruby-software.com”
}

{office : “Ruby on Rails Pvt Ltd”,
location : “India”,
Address : “Pamba Building
Trivandrum Technopark,
Kerala, India -695581”,
Phone: “+91 9446472021”,
Email: “contact@ruby-software.com
}

Alice: Oh this looks like a JSON file.
Bob: Exactly, Document type databases uses JSON documents or as a matter of fact any document, like XML, YAML, etc. to store records.
So you can see now that this is kinda structured, yet no definite schema is defined.

Alice: Okay, so you can get specific data out of an object which was not possible with key-value pair, like if only we want to know the phone number, we can query for that specifically.
Bob: Exactly. Moving on, the next one on the list is Column-Family type. In this one for there is a column containing values and it is accessed by a key. This may sound like a RDBMS model, but it is not. See here you have a row key which points to a column which contains a key-value pair data.
And most importantly it has no relationship, foreign or primary key as in RDBMS.

 

Bob: Okay! I hope you remember the famous ACID property that RDBMS always boast about ?
Alice: Yes, Atomicity, Consistency, Isolation and Durability.

Bob: Exactly the data model we so far discussed do not have that property, actually they kinda don’t need them as they are storing data as a single unit. Anyway our last data model can however stand tall and say that it support ACID. This is called as Graph data model.

Alice: Like old school graphs with nodes and vertices ?
Bob: Exactly, here each node stored data about the object and vertices denotes the relation between them.

Alice: Hey stop there, you said relations!. So it’s relational ?
Bob: No, RDBMS has relationship, in other word primary key, foreign key, joins etc. but graph have relation and not relationship. Let see a diagram to understand how this work.

 

Bob: So we have three different objects in the form of nodes, and their relation is defined with the label, so we both are members of a group named Chess and we between us our relation states that we know each other.

Alice: okay but how am I gonna fetch data from these nodes?, how will I know which node contain which data?.
Bob: Graph databases uses a query language called cypher, it actually finds data using query that would look like pattern matching. For eg:

 

START a = node.people(name=”Alice”)
MATCH (a)-[:KNOWS]->(x)
return x
Alice: So NoSQL has a lot of advantage over RDBMS ?
Bob: Some advantages, some disadvantages. Use of NoSQL will fetch you some advantage over RDBMS
Eliminates Impedance mismatch problem.
Ability to store unstructured data easily.
Cluster Friendly.

Alice: Okay I am losing it again, “Impedance Mismatch” ?
Bob: Hmm, let’s put it this way, we use Object Oriented Programming and so before it is stored in a database, we have everything in one piece but when we are going to place it in the database, we’d need to rip parts of data and store it in separate table that are related to each other. Again when we have to reproduce the same we need to access all the relational model, fetch data from them and merge them together as a single object. So here we can see the mismatch between a relational model and object model.
Impedance mismatch deals with this problem.

Alice: Okay, So is there any role for ORM to reduce it.
Bob: Not really, ORMs like Active Records help in converting object to relation model and relational to object model, making it easy for the developers but the mismatch is still there.

Alice: So NoSQL seems really good, is it gonna replace RDBMS ?
Bob: No, NoSQL databases have a very narrow focus: they are designed primarily for storage, and offer very little functionality beyond.
Because of the way data is stored and managed in a NoSQL database, data consistency might well end up being a concern. NoSQL puts performance and scalability first; consistency isn’t really a consideration.
Also it Doesn’t Play Nice with Analytics.

Alice: So you mean it has an area of interest.
Bob: Yes, depending on what exactly is expected of the product and what kind of data we are processing, we need to choose between RDBMS and NoSQL.

Alice: Okay.
Bob: I am gonna leave you with your thought here. Bye buddy and you people can post questions as comments or actually drop in a comment on the post. 😉