扩展引用模式与子集模式

MongoDB's $lookup stage joins collections at query time by performing an in-memory hash join. For frequent, high-traffic queries, this join cost can dominate latency. If your order list endpoint performs a $lookup to fetch customer names and emails for every order in every request, you pay the join cost every single time. The Extended Reference Pattern eliminates this cost by embedding a targeted subset of the referenced document's fields.

The Extended Reference Pattern embeds a carefully selected subset of fields from a referenced document directly inside the referencing document. Instead of storing only a customer _id in an order and looking up the customer for every order display, embed the customer's name and email — the fields needed to render the order — directly in the order document. The full customer record still exists separately for updates.

Only duplicate fields that are read frequently alongside the referencing document and change rarely. A customer's name and email address are good candidates — they are needed to display orders and rarely change. A customer's billing address or loyalty points balance are poor candidates — they change often and would require updating all embedded copies whenever they change. The goal is to eliminate joins on the hot read path without creating an impossible sync burden.

When a customer changes their name (an infrequent event), you must update the customer's main document and all order documents that embed their name. This is called a write fan-out. Use updateMany() to propagate the change. The key insight is that this infrequent write cost is worth paying if it eliminates join overhead from thousands of daily reads.

The Subset Pattern addresses a different challenge: when a document embeds an array that grows very large over time, every read fetches the entire array — even if the application only ever displays the first N elements. A product with 5,000 reviews embeds all 5,000 in a single document, but the UI shows only the top 10. The Subset Pattern splits the array: keep the most recent or most relevant N items in the main document and move the rest to a separate collection.

Keep the embedded subset up to date using a $push with the $slice modifier. After adding a new review to the recentReviews array with $push, apply $slice: -10 to trim the array to the last 10 elements. This is a single atomic operation — MongoDB atomically pushes and slices in the same update.

For the common case — displaying a product page with recent reviews — read the main product document and use the embedded recentReviews. For 'load more' or pagination, query the separate reviews collection with the product's _id. This two-tier approach gives fast common-case performance without sacrificing the ability to access all reviews when needed.

Extended Reference duplicates fields from a referenced document into the referencing document to eliminate joins on read. It handles the case of one-to-many relationships where the 'one' side has fields needed alongside every 'many' record. Subset Pattern duplicates the most relevant N elements of a large array into the main document to avoid loading thousands of items on every read. Both trade write complexity for read performance.

Avoid these patterns when the duplicated data changes frequently — the write fan-out cost becomes prohibitive. If customer emails change daily, propagating to millions of orders is impractical. Also avoid them when data consistency is critical and eventual propagation is unacceptable — in the window between a name change and the fan-out completing, some orders will show stale data. For strict consistency requirements, stick with references and accept the join cost.

In an e-commerce platform, orders are read far more often than customers update their profiles. Embedding the customer's shipping address snapshot at order time (Extended Reference) is actually correct business behaviour — orders should remember the address used at purchase, even if the customer moves later. This is a case where the pattern aligns with domain logic, not just performance, making it doubly appropriate.

Before applying these patterns, measure baseline performance with explain('executionStats') to identify where read latency is actually coming from. After applying a pattern, remeasure to confirm the improvement. Use db.collection.stats() to compare average document sizes and check that the embedded fields are not pushing documents close to the 16 MB limit. Patterns should be justified by data, not assumed to always help.

Test your understanding of MongoDB & NoSQL Databases concepts from this lesson.

In this lesson you learned: the Extended Reference Pattern embeds selected fields from a referenced document to eliminate joins on hot read paths — best for fields that are read often and change rarely, the Subset Pattern keeps the most relevant N array elements in the main document while archiving the rest in a separate collection, and both patterns trade infrequent write fan-out for dramatically faster reads. Next up we explore the Polymorphic and Schema Versioning Patterns.