Let's take an example of four documents,10 MB,18 MB,
and then 10 and 18 with some binary data within them.
The first one is a straightforward 10 MB document,
which has normalized types as embedded.
Think of a movie with a bunch of actors in it, it's 10 MB,
all the data is within the document.
Great candidate to store as a straight as is document, just save it as it is.
Query the data and
you can display the contents back to the client through a driver application.
18 MB document of query-able data with normalized type as embedded.
Let's take the same movie example.
Right, now you have a lot more information with the role,
you have a role actor, actor ID,
actor biography, picture and now the data is becoming bigger and bigger, right.
But the problem is this is 18 MB's the data size.
We know that Mongo has a size limitation of 16 MB, right?
So this will be a problem because Mongol will complain if you try to
insert this data.
Now since the data is query-able, meaning it's still key value pair object arrays,
whatever, but it's still a key value pair.
A good design here might be,
you may want to take the actor information in my example or directors or
other nested data, right, and move it to a different collection and
then make them a one-to-one or a one-to-many, whatever the relationship.
It's going to be linked relationship.
So you will still have the role information and
the actor ID, through which you can go to the actor collection and get the data.
The third example is a 10 MB of image blob.
So it's a binary data.
But there is some query-able data stored as a regular document, right?
Because Mongo does support binary.
So you can just pretty much take the document, and
save it as a, you know, just a regular document.
Having said that, since you have blob of binary data in this 10 MB document,
you can save the query-able data in the metadata section, and then use GridFS
to break the image into multiple chunks, because that's another possibility.
But 18 MB document, the last example of an image, now this is a really,
a good candidate for GridFS for two reasons.
One, the size obviously exceeds 18 MB so you have the 16 MB limitation.
That will will force you to break the file apart, but
since there is no normalized type here, you can do a linking.
So, you really have to really go down the grid at the spot, and
put all credible data into the metadata section or the file section.
Yeah, so just to give you an example,
from a very high level of when GridFS will come in,
because Grid FS is completely independent of any other restriction that Mongo has.
16 MB's is one restriction that will force you to go down the GridFS path.
But if the document is query-able data, then you may still want to stick with
just non GridSF solution where we can maybe look at linking and
moving the normalized data into a different collection like the actor and
the movie and all that.
But if it's opaque binary data that cannot be queried,
then GridSF is a good candidate for you to go down that path.