Loading post…
MongoDBExplainer
Data Modeling and Schema Design for MongoDB Search Part 1: Practical Considerations
Summary
Data modeling for MongoDB Search requires balancing conceptual, logical, and physical schema decisions against workload demands and system constraints. The $search stage must be the first in an aggregation pipeline, queries a single Search index, and runs against a single collection, with results returned in relevancy order. The underlying Lucene engine supports two mappings for arrays of sub-documents: default document mapping flattens fields into one index object, while embeddedDocuments mapping creates separate Lucene index objects per sub-document. Embedded mapping enables cross-field matching within sub-documents but explodes the index object count and causes heavy reindexing on any update, as the entire block is deleted and re-added. This post establishes the foundational concepts and physical constraints that will inform schema patterns in Part 2.
Context
Part 1 of a series on data modeling and schema design for MongoDB Search. It covers conceptual, logical, and physical data models, how the $search stage fits into the aggregation pipeline, and the trade-offs between document and embeddedDocuments mappings for arrays of sub-documents.
Approach / What changed
A methodology for schema design in MongoDB Search that involves analyzing use case workloads, understanding physical constraints (single collection/index, $search as first stage in aggregation pipeline), and selecting between document and embeddedDocuments field mappings based on cross-field matching needs and index object scale.
Takeaways
The $search stage must be the first stage in an aggregation pipeline and queries a single MongoDB Search index tied to one collection.
EmbeddedDocuments mapping creates separate Lucene index objects per sub-document; any update reindexes the entire block, causing thrash as the number of embedded elements grows.
Default document mapping flattens nested fields into a single Lucene index object, preventing cross-field matching within sub-documents but avoiding index object explosion.
FAQ
When should I use embeddedDocuments mapping instead of default document mapping?
Use embeddedDocuments when you need to match across multiple fields within the same sub-document, such as finding a parent with a child aged 5 and named Kid2. Default document mapping flattens fields into one index object, preventing such cross-field matching.
Why does updating a document with many embedded documents cause performance issues?
Each update triggers a delete and re-add of the entire block of Lucene index objects for that document. The more embedded documents, the heavier the reindexing cost, which can significantly impact performance.
How does the $search stage affect aggregation pipeline performance?
$search must be the first stage and returns all matching documents unless limited. Post-search stages like $group can drastically reduce performance if applied to large result sets. Design for limited results and use searchAfter for pagination.
Source and freshness
- Source
- mongodb.com
- Published
- Added to Yomu
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.