Best Practices for Data Modeling in MongoDB

Modify Your Data Model

As the needs of your application change, you should design your schema iteratively and modify your schema. MongoDB's provides ways to seamlessly modify your schema without downtime. However, it can still be difficult to modify large-scale schemas that are used in production.

Consider the following example:

You're tasked with building the backend of an online user learning platform that stores information on courses and their lessons. Initially, the platform only needs to store the following basic information for each course:

• Course title

• Instructor

• Description

• Lessons, embedded as an array of sub-documents inside each course document. At this time, each lesson sub-document only contains a title, description, and presentation slides.

As the platform evolves, each course needs additional learning and testing formats, such as videos, quizzes, assignments, and external resource links. Embedding all of this new data in each course document would make the data model too complex.

Instead, consider creating a separate lessons collection. This way, you can link the course and lessons collections by using reference IDs. By using references, each lesson can include different content types and be more flexible for future format changes.

Enforce Data Consistency

If you duplicate data in your schema, you need to decide how to keep your data consistent across multiple collections. For example, an e-commerce platform likely requires continuously up-to-date data to provide the real-time status of its product stock. On the other hand, applications that handle data for longer-term strategic decisions, such as social media analytics, can tolerate reading slightly stale data.

You can enforce data consistency in your application with any of the following methods:

• Embedding related data

• Transactions

• Atlas Database Triggers

To learn more about each data consistency enforcement method, their use cases, and their performance tradeoffs, see Data Consistency.

Atomicity

In MongoDB, a write operation is atomic on the level of a single document, even if the operation modifies multiple embedded documents within a single document. This means that if an update operation affects several sub-documents, either all of those sub-documents are updated, or the operation fails entirely and no updates occur.

A denormalized data model that uses embedded documents and arrays combines all related data in a single document instead of normalizing across multiple documents and collections. This data model allows atomic operations, in contrast to a normalized model where operations affect multiple documents and collections. For an example data model that provides atomic updates for a single document, see Model Data for Atomic Operations.

For data models that store references between related pieces of data, the application must issue separate read and write operations to retrieve and modify these related pieces of data.

For situations that require atomicity of reads and writes to multiple documents (in a single or multiple collections), MongoDB supports distributed transactions, including transactions on replica sets and sharded clusters.

For more information, see Transactions.

Data Lifecycle Management

Data lifecycle management refers to the process of managing data from creation and storage to archiving and deletion. To ensure schema cost-efficiency, performance, and security, consider data life cycle management when making data modeling decisions.

If your application requires some data to persist in the database for a limited period of time, consider using the Time to Live or TTL feature. For example, TTL collections could be useful for managing user login sessions on a web application, where sessions are set to automatically expire after 30 minutes of inactivity. This means that MongoDB automatically deletes the session documents after the specified time period, helping you keep your session collection small for efficient querying.

Additionally, if your application only uses recently inserted documents, consider Capped Collections. Capped collections provide first-in-first-out (FIFO) management of inserted documents and efficiently support operations that insert and read documents based on insertion order.

Hardware Constraints

When you design your schema, consider your deployment's hardware, especially the amount of available RAM. Larger documents use more RAM, which may cause your application to read from disk and degrade performance. When possible, design your schema so only relevant fields are returned by queries. This practice ensures that your application's working set does not grow unnecessarily large.

Small Documents

Each MongoDB document contains a certain amount of overhead. This overhead is normally insignificant but becomes significant if all documents are just a few bytes, as might be the case if the documents in your collection only have one or two fields.

Consider the following suggestions and strategies for optimizing storage utilization for these collections:

• Use the _id field explicitly.

  MongoDB clients automatically add an _id field to each document and generate a unique 12-byte ObjectId for the _id field. Furthermore, MongoDB always indexes the _id field. For smaller documents this may account for a significant amount of space.

  To optimize storage use, you can explicitly specify a value for the _id field when inserting documents into the collection. This strategy allows applications to store a value in the _id field that would have occupied space in another portion of the document.

  You can store any value in the _id field, but because this value serves as a primary key for documents in the collection, it must uniquely identify them. If the field's value is not unique, then it cannot serve as a primary key as there would be collisions in the collection.

• Use shorter field names.

  Note

  While shortening field names can reduce BSON size in MongoDB, it's often more effective to modify the overall document model to reduce BSON size. Shortening field names might reduce expressiveness, and does not affect the size of indexes, as indexes have a predefined structure that does not incorporate field names.

  MongoDB stores all field names in every document. For most documents, this represents a small fraction of the space used by a document; however, for small documents the field names may represent a proportionally large amount of space. Consider a collection of small documents that resemble the following:

  { last_name : "Smith", best_score: 3.9 }

  If you shorten the field named last_name to lname and the field named best_score to score, as follows, you could save 9 bytes per document.

  { lname : "Smith", score : 3.9 }

• Embed documents.

  In some cases you may want to embed documents in other documents and save on the per-document overhead. See Collections with a Large Number of Small Documents.