What exactly is an unstructured data and why to use Non-relational DBMS for that?

Question

I read some posts online about Unstructured data like this one.

It says

Unstructured data is information that is not arranged according to a pre-set data model or schema, and therefore cannot be stored in a traditional relational database or RDBMS.

But RDBMS allow BLOB storage. So we can store unstructured data in traditional RDBMS.

The examples that they have given for unstructured data are Email, Text files, Media files etc. First of all, how are all these types unstructured? And even if they are, how can a Non-relational DBMS like MongoDB store/retrieve it better than RDBMS' BLOB storage?

A common example for unstructured data that I found almost everywhere is storing products' information in a e-commerce company like Amazon. Every product has different attributes and so in a NoSQL DBMS like MongoDB we can have a collection called Products in which we will have all the products' information. But we can store this data using RDBMS by creating a separate table for each product. This will probably a much cleaner way to store the data. Then why to use a non-relational DBMS for that?

So my questions are:

1. What exactly is an unstructured data in the context of databases?
2. How is a non relational DBMS like MongoDB better for unstructured data than a RDBMS?
3. Can you give a real life example of unstructured data?

Thank you!

Answer 1

Unfortunately the answer to when a NoSQL database system is better than a RDBMS is a little subjective which is why it's highly debated. A lot of misinformation has caused the incorrect connotation that a NoSQL database is faster than a RDBMS, particularly with big data, which isn't necessarily true. This connotation is based on the origination story of NoSQL databases being used by companies who do have big data who were trying to solve a scale problem actually, but not because of scaling performance rather one of flexibility to allow them the ability as developers / infrastructure administrators to scale faster. (In my opinion, with the availability of modern Cloud services and decoupled services like Azure and AWS, that problem is mostly solved in an alternative way now.) But to this day, those same companies, such as Facebook still leverage a RDBMS in addition to a NoSQL database system, for likely similar amounts of data, because it's not a question of database performance, rather of flexibility and using the right tool for the right job dependent on use case.

At a high level, as previously mentioned, NoSQL databases have the advantage of flexibility at the trade off of consistency, which is a trade-off between the ACID Database Principals for eventual consistency. This flexibility allows a NoSQL database to store unstructured, semi-structured, and highly variable structured data; and it allows that database to be distributed easily when horizontally scaling across a multi-node database cluster. Because of the flexibility with the schema of the data it can store, it doesn't have to worry about schema changes in one node vs another node in a multi-node cluster. Additionally, because of its ability to be eventually consistent, it generally doesn't have to worry about having 100% of the same data across every node in the cluster.

Because of its flexibility for scaling horizontally, one can loosely argue (at a high level) that this is where the performance benefit comes from when using NoSQL over a traditional RDBMS. But the other tradeoffs are your ability to transform and query the data become limited when you're dealing with a NoSQL database due to it's lack of a consistent schema. I want to be objective, so I will credit MongoDB with offering a multitude of ways to query the data which I believe are also a little more procedurally programmatic by design, so may be a little user-friendly to a developer who is not very experienced with traditional relational logic. But there's only so much one can do when guaranteed eventual consistency at best as opposed to the actual guaranteed consistency of a RDBMS.

As far as actual use-cases for a NoSQL database, it depends heavily on the schema of the data (or lack thereof) and the developer's specific use cases and types of querying they'll need to support. Some of the examples you've read are potential use cases, such as an Email for example. Emails are semi-structured in schema, as far as I would define them. They have a few consistent fields like the From, SentDateTime, ReceivedDateTime, and Subject but they all have highly variable fields like the To, CC, BCC and the Body. So a NoSQL database could make sense in the scenario where the type of querying you'll ever do has predicates dependent only on the From and/or SentDateTime field. Those would be your keys in your Emails table, and the Body of the message and the To field will be the rest of your entity (maybe in a JSON format) that's stored in the table. (Note the term table is used loosely here for conceptualization.)

Now of course you're saying to yourself "but you can accomplish just the same in a RDBMS" - which is true, but again the flexibility of NoSQL with its eventual consistency allows you to then take the above example table and shard it across multiple nodes more easily when horizontally scaling. So while even some of the main features of a NoSQL database are available in a traditional RDBMS (in a sense I almost see NoSQL being a subset of RDBMS from a features perspective) it's flexibility and the rules it has to follow differ enough from a traditional RDBMS, allowing it a place in the world we live in.

That being said, over time a lot has changed, even NoSQL systems in their original sense have changed a lot and adapted to the progression of the database world (or the ones who haven't die off). The lines between NoSQL and RDBMS continue to blur (for the better) as both grow to accommodate the things they're missing from one or the other. For example, ACID compliant NoSQL databases now exist, and RDBMS databases with much easier horizontal scaling capabilities exist as well.