There are plenty of situations where data just doesn't work well as a table.
In a situation where we need to store chat logs between customer service and customers through a web interface. These chats could be very short, or very long — some chats may only be 2 or 3 messages, while others may be hundreds or thousands.
For each message in the chat, we want to store metadata associated with the message, like which party sent the message, the time it was sent, the time the other party read the message, etc. This is a great use case for a NoSQL database because it would be a very poor fit for a relational database.
For starters, each chat can be any size, meaning that we can’t just clearly define a table that links which messages belong to which chat. If every chat had only five messages, we might be able to make it work, with a column for “message 1”, “message 2”.
A Document Store is a database that stores records as unique documents in the database. These documents can be crazy long, and can even contain other documents inside of them! The chat log example we saw above is a prime use case for a document store.
In a document store, we could store each message and its accompanying metadata as a document, and then embed each of those documents in order inside. This way, we can easily access the data as needed.
In these Document Stores, each document contains key-value pairs (similar to dictionaries), with the actual data being stored as the value. This makes Document Stores incredibly flexible because each document can be unique. There is no constraint saying each document must have the same keys! This makes it great for working with data where we don’t know what shape it will take or when we don’t know what data will be stored at all. This would be a problem in a relational database because we would need to know what column the data belongs in before we could store it.
While this flexibility makes it easy for us to store data easily, this also makes it harder for us to query data and get exactly what we need. Since each different document can potentially have its own Schema, this means that we have to know exactly what we are looking for.
This also means that we have to be diligent in our naming because chatLog is different than ChatLog. This means that if we run a query across all documents to get all data with the key chatLog, we’ll completely miss any data where the key is written as ChatLog!
Advantages of NoSQL
1. Faster Inserts/retrievals
In NoSQL databases, data can be duplicated across records.
Also, since all the data is stored within a single record, inserting it into the database can be done in a single call for NoSQL databases, instead of making multiple calls to update different tables with SQL databases.
2. Flexible schema
NoSQL databases do not require a strict schema and each record can have whatever key/value pairs it wants.
3. Designed for scalability
NoSQL databases are designed with horizontal additions.
4. Aggregations
NoSQL stores all its data in a record
Disadvantages of NoSQL
1. Not good for updates
NoSQL databases do not guarantee consistency across their replicas since they maintain a soft-state. NoSQL databases, on the other hand, have to iterate over all records, changing the location for every single record.
2. Not good for filtering
If you want to query a record with some filters, it becomes relatively more expensive for NoSQL databases since all the records have to be fetched first, and the filters are applied to each record before being returned
3. Joins are difficult
Since there are no implicit relations between NoSQL tables, it’s expensive to parse records and join them by the key.
