NoSQL databases have skyrocketed in popularity over the last few years.
Two major reasons for this are scalability and flexibility.
👉 NoSQL databases are scalable horizontally, allowing them to handle large amounts of data distributed across multiple servers. Most NoSQL databases support techniques like sharding & replication out-of-the-box.
👉 Also, NoSQL databases are more flexible because of their schema-less structure. This makes them great for storing unstructured as well as semi-structured data such as text, images, and videos.
These reasons are enough to make any developer consider NoSQL databases as a viable option when choosing a database for an application.
If the application is new and requirements are not clearly mapped out, the pull of NoSQL databases becomes even stronger.
However, NoSQL databases come in multiple flavors.
Each type of NoSQL database has a particular philosophy and works best for a specific scenario.
Hello 👋 and welcome to a new edition of the Cloud & Backend newsletter.
In this post, I take you through the 4 types of NoSQL databases and when you should use a particular type.
🏀 Document Database
This is probably the most popular category of NoSQL databases. Examples include heavy-weight names like MongoDB & Couchbase.
Chances are that you might have already come across document databases as lots of new projects tend to start with them. MongoDB is particularly popular in big as well as small companies.
In a document database, the data is stored in the form of documents (JSON, BSON, or XML). These documents can be designed to be much closer to the domain-level data objects within the application.
This is a great thing because it means less translation is required to assemble and disassemble data when moving it back and forth between application and storage.
You get far more flexibility with a document database when compared to a SQL database.
In my view, document databases are great for requirements that involve:
nesting of data
no-fixed or changing schema
🔑 Key-Value Store
This is arguably the simplest type of NoSQL database out there. Examples include Redis, etcd and Zookeeper
Every data element is stored as a key-value pair. The key is an attribute name. Value is the actual data or object.
At a fundamental level, a key-value store looks a lot like a relational database with just 2 columns - key and value.
There are many use cases where a key-value store is an ideal choice:
caching frequently used data
shopping carts
user profile information
🗿Column-Oriented Database
In a column-oriented database, the data is stored as a set of columns. This is unlike a relational database where data is stored in rows and read row by row.
Examples of column-oriented databases include Apache Cassandra & Apache HBase.
See the below illustration that compares the data storage approach between a row-oriented and column-oriented database.
The advantage of this comes when you have to run analytics on a small number of columns for aggregation or calculation.
The columns can be read directly without consuming memory in fetching unwanted data. An example is calculating the total salary paid out in a year.
Of course, column-oriented databases have downsides. They are not strongly consistent and writes for each column require multiple write events on the disk.
🪁 Graph Databases
A graph database is based on the relationship between data elements.
Each element is a node. The connections between these nodes are called links. Think of social media as a collection of people (nodes) that are connected to each other.
Examples of graph databases are Neo4j, Amazon Neptune, etc.
Unlike a relational database where links are implied, graph database stores connections as first-class elements. This helps avoid the overhead of joining multiple tables in a typical SQL database.
Despite their advantages, the use of graph databases is not as common. A few places where they can shine are building knowledge graphs of information and map-like applications.
🤖 Over To You
Have you ever worked with NoSQL databases?
If yes, which type of NoSQL database was it?
And was it a good experience using it?
Write your thoughts in the comments section.
If you are finding this newsletter valuable, consider doing any or both of these:
👉 Support the Newsletter - if you haven’t done so already, consider becoming a paid subscriber.
👉 Share it - Progressive Coder grows thanks to word of mouth. Share the article with your friends or colleagues to whom it might be useful!
Wishing you a great weekend ahead! ☀️
See you later.