NoSQL is picking up the pace and just in case you are planning a new application, choosing the right NoSQL database can largely govern your budget distribution since a wrong move at this point can end up costing you lots of bucks in the coming days.
Instead of beating around the bush, I shall cut to the chase right away. Firstly, this blog is only for readers who have some idea about NOSQL. Secondly, the purpose of this blog is to give you a good idea of different types of NoSQL databases so that when you go for a particular NoSQL database type, someone says to you ‘Excellent Choice Sir’. Lastly, this blog is part of the MEAN stack series I have been working on and I will be taking up MongoDB after I am done with NoSQL database types.
NoSQL is the next big thing in big data. Since the technology is relatively new undergoing innovations every now and then, it is safe to say there are no defined standards related to NoSQL database. In fact, the actual USP of these databases is that they are not confined by strict standards thus giving developers the flexibility to modify databases as per their requirements. In our previous posts we talked about what is NoSQL and why is it important. We also performed a comparative analysis between NoSQL and SQL. Now it’s time to look deeper into different types of NoSQL databases and their uses.
Because there are no fixed standards, categorizing NoSQL databases into different types is a tough challenge. But then deep inside somewhere in our hearts, we are persistent engineers. And we will categorize them anyway.
NoSQL databases most popularly get categorized into the following four types:
- Key-Value Store
- Document-based Store
- Column-based Store
- Graph-based
Key Value Store NoSQL Database
Key Value Store NoSQL databases the simplest of all. The database uses a hashtable to store unique key and pointers to each data value which in turn are stored in a schema less way, in other words data is stored in the form of keys and values, hence the name Key-Value-Store databases.
From the perspective of database ‘value’ is just meaningless data that database just stores, without caring or knowing what’s inside. For the database, it is the responsibility of the application to understand what was stored. There are no complex relations thus implementation is very easy, and since these databases only use a single primary key as access, they give great performance and can be very easily scaled.
However, they are not the ideal choice for every case-
- Since there are no column type relations in databases, updating a part of value or querying the database for a specific information is a not as easy and fast as compared to SQL databases.
- The database model is not designed to provide consistency when multiple transactions are executed. Ultimately, it is the responsibility of the app developer to make sure its consistency.
- Also as the volume of data increases (and by volume we mean in millions) maintaining unique primary key becomes more and more difficult. You would need a nifty complex character string generation algorithm just for the same.
Use Cases
Key-value databases are best utilized in the following situations:
- Storing user session data
- Maintaining schema-less user profiles
- Storing user preferences
- Storing shopping cart data
We generally avoid Key-Value Databases if
- we have to query the database by specific data value,
- we need relationships between data values
- we need to operate on multiple unique keys
Examples
- Redis
- Riak
- Amazon DynamoDB
Document Store NoSQL Database
Imagine a Key-value Store database in which instead of storing ‘value’ we are storing entire documents. If you can imagine it then you have grasped the crux of Document Store database. These documents are mainly stored in common notation formats like XML, JSON, BSON etc, therefore they give greater flexibility in querying. For example, in Key-value Store databases you can only query on the basis of primary key nut in document databases you can search by primary key and the value in documents. This is because Document Store database embeds attribute metadata related to the stored content with each document which provides a node to query the database based on the content of the document.
However it once again depends upon the app development process on how they want to maintain ‘documents’. They can have consistency in information or they can store random schema-less information in their documents.
Use Cases
Document Store databases are useful when you have to implement
- Content management systems
- Blogging platforms
- Analytics platforms
- E-commerce platforms
App developers avoid document store if they have to run complex search queries or if their application requires complex multiple operation transactions.
Examples
- MongoDB
- Apache CouchDB
Column Store NoSQL Database
Column-family databases are row-based databases. In this type of database data is stored in rows that have a unique row id, and instead of documents and ‘value’ like in Key-value store and document store databases, the data is stored in form of flexible columns.
The key difference between Column Store and SQL database is that in Column-store you don’t have to maintain consistent column numbers. You can add a new column to any row without having to add them to all the rows of the database. Because of its similarity to SQL databases, column store is easier to query than previously mentioned NoSQL databases but they are not as flexible in storing random information like document store or key-value store.
Use Cases
Developers mainly use column databases in
- Content management systems
- Blogging platforms
- Systems that maintain counters
- Services that have expiring usage
- Systems that require heavy write requests (like log aggregators)
We generally avoid Column Store databases if we have to use complex querying or if our querying patterns have to be changed regularly. And hence they are avoided if you don’t have established database requirement, a trend which we are beginning to see in new systems.
Examples
- Cassandra
- Apache Hadoop HBase
Graph Base NoSQL Database
Graph Base databases are all about edge-nodes and graph relations. You store data entities and allow users to add relations to these database entities. However, the database neither knows nor care what is stored in data entities or how it is stored. The database uses complex graph structures complete with the ability to define edges, nodes and node properties. This not only gives greater abilities in querying relational data but also provide index-free searches, a problem that plagues previously mentioned NoSQL types.
Moreover, data migration from SQL to NoSQL or Graph Base to other type of NoSQL is stellarly easy in Graph Base databases as compared to Column Store, Document Store or Key-Value Store.
Use Cases
Graph-based databases are enormously useful in applications that have connected data, such as social networks, routing info centers, recommendation engine applications, spatial data and mapping applications and other applications requiring unique key relations. br/>
They are extremely useful in analytic applications especially those which require predictions, recommendations, and consequence-analysis engines.
Examples
- Neo4j
- GraphBase
The combination solutions
Suppose you want to create a social networking app which can save users’ profile information and connections. Which NoSQL database would you use in this case? If you use Graph-Based NoSQL database your application would be a champ in fetching user connections like friends, followers, etc, but when it comes to fetching user profile information or posting texts, the database fails miserably. However, using Document Database like MongoDB would greatly help in storing profile and post documents in such a case. But then is it the best approach? No. Instead, why not use both? The best solution for this problem is to use a Graph Database to manage connections and Document Database for managing profile and post data. A single database may not be able to overcome problem efficiently but a combination of the two will certainly do the task. That’s the way most modern apps are being designed nowadays. To know more which combination is the best for your application, let the database experts study your case and come up with the best suggestions for your model.
Conclusion
Though there are various types of databases, it is not advisable nor is it the norm to opt for a single database. More popularly, and as much sensibly, it’s the idea of using more than one database which does the trick. Now since most of these databases are in a sense ‘applications’, using them is more of an expert module integration job rather than strictly a database integration job. The information I have shared with you in this blog is good enough to get your thinking bulbs glowing to figure the best for your requirements. You may as well not shy if you decide to go ahead and contact a NoSQL database expert before choosing or deploying the database. Afterall, it’s never bad to be safe than sorry! We here at Algoworks have been using these databases since their inception and are fairly well versed with their ideation, deployment, configuration, and maintenance. So if you are facing any problem feel free to talk about it.
Rachit Agarwal
