Video Transcript (English)

In this video, you will learn about the problems that arise when we create data models that aren’t scalable, and how to avoid them.

MongoDB’s first principle of “data that is accessed together should be stored together” is mostly because your query pattern (how you access your data) needs to align with your data model, in order to have optimum efficiency of query result time, memory usage, CPU usage, and storage. This is a very complex topic. So in this lesson, we will teach you some of the basics.

First, when creating a data model, we want to avoid documents that are unbounded. Unbounded means that the document size grows infinitely.

This can happen when we use document embedding.

Here’s an example.

Let’s examine this sample document model of a blog post and its comments. Currently, all the `comments` on one blog post are in an array in the `blog_post` document.

This looks OK, but what if we get a lot of comments on this post? What if we had thousands of comments on a post?

This model allows us to easily retrieve all the blog post’s comments in a single read, but problems will arise as the `comments` array grows larger.

For example, if we get thousands of comments, the document will get larger and take up more space in memory.

Also, this data model may have an impact on write performance. As comments are added to each document, the entire document is rewritten into MongoDB data storage.

Furthermore, it will be difficult to perform pagination of the comments. Comments can’t be easily filtered from a single post, so all comments will have to be retrieved and then filtered in the application.

Also, there is a maximum document size of 16 MB, so we’ll eventually have storage problems.

The benefit of this model is that we can retrieve all of the documents in a single read—but that's probably not the functionality we'll need. So, the model creates problems without providing any real benefit.

In this case, embedding comments probably isn’t a good idea.

Instead, we can break our data up into multiple collections and use references to keep frequently accessed data together.

For example, here are two collections called `blog_post` and `comments`.

We can use a blog_entry_id field as a reference between the two collections.

I hope this lesson helped to explain how our data model has to scale, and how it has to match our query pattern. Ultimately, you don’t want

To exceed the document size limit of 16MB

Poor query performance

Poor write performance

Too much memory being used

And effective data modeling will help prevent all those things.

Great work!