NoSQL Databases Variants

With extensive variety of options and user-friendliness, NoSQL Databases have become an ultimate choice. From developing content variety to bringing flexibility to store data, NoSQL Databases provide numerous vital options which can be availed to progress with effectiveness. There was a special need of NoSQL databases, which caused them to born. Some of the reasons to look for NoSQL can be summarized as follows:

1. Schema Free:

We need some flexible structure to store data. In some environments, we are not sure about the structure of data which would be added by user on run time. In that scenario, we usually serialized custom data and save as string format.

2. Variety of User Behavior:

Nowadays, single user can perform multiple actions with a lot of diversity. People are looking forward to systems which can tackle every user’s behavior. Not even save/parse behavior, but can also perform filters and analytics on top of it. Schema based databases can’t handle such variety in one structure. If we go for multiple structure for each behavior then RDBMS would have a huge load.

3. Variety of Content:

Systems are producing and handling a variety of content nowadays. In one system, there can be user behaviors, structured data, custom data, logs, tracking, etc. For such a variety of content, RDBMS is not suitable to handle all in one.

4. Availability/Scaling:

We need such systems which can stay available and can scale seamlessly with low cost. RDBMS can have good availability but their scaling is costly and panic.

NoSQL Variants:

When we say due to a variety of data, RDBMS is not suitable then there comes another question. Can one single NoSQL database be suitable in this scenario? The answer is “NO!”, because there are many variants of NoSQL databases which can be implemented in different scenarios. In each scenario, that family of database performs well. We can categorize those databases into the following families:

• Key/Value Family
• Column Family
• Graph Family
• Document Family
  .

All the above mentioned are NoSQL databases and are suitable in different situations. Lets explore these one by one.

1. Key/Value Databases:

• Collection of Key/Value Pairs
• You can think of these as Associated Arrays in PHP, Hash in Ruby or Dictionary in Java
• You can consider these as global hash in your programs
• These are designed to handle huge load
• These have multiple implementation based on infrastructure:
  • In Memory i.e. Memcache
  • On Disk i.e. Redis, SimpleDB
  • Distributed i.e. Dynamo, Voldemort

2. Column Family Databases:

• These are similar to Key/Value Pair family in terms of infrastructure and use
• One addition they have is that you can have multiple values against one key
• You can consider it as associated array which has nested associated array on each value
• These are not supported to be used up to nth level, but for 2 levels only
• These are inspired by Google Big Tables
• Examples are HBase, Cassandra

3. Graph Family Databases:

• Inspired by Mathematical theory Eular Graph Theory
• When you want to model real world environment where different data entities have very complex connections to each other, then Graph Databases can save your life
• They can optimize the querying complex relations of objects to each other
• Examples are Neo4j, InfiniteGraph, HyperGraph DB and Sones

4. Document Family Databases:

• Can be compared to Key/Value databases with a difference that each value itself can be a document
• This theory can be applied to nth level
• You can think of popular JSON format when considering Document databases
• Inspired by Lotus Notes
• Flexible Schema of each document
• Documents stored in JSON/BSON formats
• Examples are CouchDB and MongoDB

{ 
   “day”: [ 2010, 01, 23 ],
   “products”: {
      “apple”: { “price”: 10 “quantity”: 6 },
      “kiwi”: { “price”: 20 “quantity” : 2 }
   },
   “checkout”: 100
}

Conclusion:

As we went through different variants of NoSQL databases, we came to know in this side of the world that we have variety as compared to RDBMS world, so in your next application you must consider analyzing your requirements and use any of these if appropriate.