What’s the most frequently asked question about schema designs?
“I’m designing an application to do X. How do I model the data?”
This 12-part blog series is designed to answer this question by providing guidance on data modeling patterns for 12 common use cases.
To help you get to a blog that can help you build now, the accompanying chart maps the schema design patterns to a variety of common applications.
MongoDBDesign pattern summaries
Approximation: The Approximation Pattern is useful when expensive calculations are frequently done and when the precision of those calculations is not the highest priority.
Pros
- Fewer writes to the database.
- Maintain statistically valid numbers.
Cons
- Exact numbers aren’t being represented.
- Implementation must be done in the application.
Attribute: The Attribute Pattern is useful for problems with big documents with many similar fields, but also a subset of fields that share common characteristics that we want to sort or query, when the fields we need to sort are only found in a small subset of documents, or when both of those conditions are met within the documents.
Pros
- Fewer indexes are needed.
- Queries become simpler to write and are generally faster.
Bucket: The Bucket Pattern is a great solution for managing streaming data, such as time series, real-time analytics, or Internet of Things (IoT) applications.
Pros
- Reduces the overall number of documents in a collection.
- Improves index performance.
- Can simplify data access by leveraging pre-aggregation.
Computed: When there are very read-intensive data access patterns and that data needs to be repeatedly computed by the application, the Computed Pattern is a great option to explore.
Pros
- Reduction in CPU workload for frequent computations.
- Queries become simpler to write and are generally faster.
Cons
- It may be difficult to identify the need for this pattern.
- Applying or overusing the pattern should be avoided unless needed.
Document versioning: When you need to maintain previous versions of documents in MongoDB, the Document Versioning Pattern is a possible solution.
Pros
- Easy to implement, even on existing systems.
- No performance impact on queries on the latest revision.
Cons
- Doubles the number of writes.
- Queries need to target the correct collection.
Extended reference: You will find the Extended Reference Pattern most useful when your application is experiencing lots of JOIN operations to bring together frequently accessed data.
Pros
- Improves performance when there are a lot of JOIN operations.
- Faster reads and a reduction in the overall number of JOINs.
Cons
- Data duplication.
Outlier: Do you find there are a few queries or documents that don’t fit into the rest of your typical data patterns? Are these exceptions driving your application solution? If so, the Outlier Pattern is a wonderful solution for this situation.
Pros
- Prevents a few documents or queries from determining an application’s solution.
- Queries are tailored for “typical” use cases, but outliers are still addressed.
Cons
- Often tailored for specific queries, therefore ad hoc queries may not perform well.
- Much of this pattern is done with application code.
Pre-allocation: When you know your document structure and your application simply needs to fill it with data, the Pre-Allocation Pattern is the right choice.
Pros
- Design simplification when the document structure is known in advance.
Cons
- Simplicity versus performance.
Polymorphic: The Polymorphic Pattern is the solution when there are a variety of documents that have more similarities than differences and the documents need to be kept in a single collection.
Pros
- Easy to implement.
- Queries can run across a single collection.
Schema Versioning: Just about every application can benefit from the Schema Versioning Pattern, as changes to the data schema frequently occur in an application’s lifetime. This pattern allows for previous and current versions of documents to exist side by side in a collection.
Pros
- No downtime needed.
- Control of schema migration.
- Reduced future technical debt.
Cons
- Might need two indexes for the same field during migration.
Subset: The Subset Pattern solves the problem of a working set exceeding the RAM capacity due to large, data-heavy documents not being used by the application.
Pros
- Reduction in the overall size of the working set.
- Shorter disk access time for the most frequently used data.
Cons
- We must manage the subset.
- Pulling in additional data requires additional trips to the database.
Tree: When data is of a hierarchical structure and is frequently queried, the Tree Pattern is the design pattern to implement.
Pros
- Increased performance by avoiding multiple JOIN operations.
Cons
- Updates to the graph need to be managed in the application.
Conclusion
The MongoDB document model provides extensive data modeling flexibility. That flexibility is incredibly powerful but needs to be harnessed to support your application’s data access patterns.
Keep in mind that you aren’t restricted to one pattern. Schema design patterns can be used together. For example, Schema Versioning can be used in conjunction with any of the other patterns as your application evolves.
These 12 blogs on schema design patterns offer the knowledge to harness the power of MongoDB, the flexibility of the document model.
Learn more about MongoDB Atlas and how to apply these design patterns to build your next application.