MongoDB Academy · Lezione

Pattern Extended Reference e Subset

I discenti incorporeranno un sottoinsieme selezionato dei campi consultati più frequentemente da un documento referenziato, eliminando le join $lookup nei percorsi di lettura più utilizzati.

Pattern Extended Reference e Subset è una lezione MongoDB Academy gratuita su CoddyKit. Questa è la lezione 2 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento MongoDB Academy, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso MongoDB Academy include 4 lezioni in totale.

Parti di questa lezione non sono ancora state tradotte e vengono mostrate in inglese.

The $lookup Performance Problem

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

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.

// Without Extended Reference: requires $lookup on every order read
{ orderId: 'ORD-1234', customerId: ObjectId('...'), total: 99.99 }

// With Extended Reference: order carries the fields it needs
{
  orderId: 'ORD-1234',
  customer: {
    _id: ObjectId('...'),       // reference for updates
    name: 'Alice Smith',        // duplicated for fast reads
    email: 'alice@example.com'  // duplicated for fast reads
  },
  total: 99.99,
  status: 'shipped'
}

Choosing Which Fields to Duplicate

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.

Handling Updates to Duplicated Fields

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.

// Update the source document first
await db.collection('customers').updateOne(
  { _id: customerId },
  { $set: { name: 'Alice Johnson' } }
)

// Then propagate to all embedded references
await db.collection('orders').updateMany(
  { 'customer._id': customerId },
  { $set: { 'customer.name': 'Alice Johnson' } }
)

The Subset Pattern: Trimming Large Arrays

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.

// Anti-pattern: all 5000 reviews in the product document
{
  _id: productId,
  name: 'Widget Pro',
  reviews: [ /* 5000 review objects */ ]  // fetched on every product read
}

// Subset Pattern: only recent 10 reviews in main document
{
  _id: productId,
  name: 'Widget Pro',
  recentReviews: [ /* 10 most recent */ ],  // fast, always-displayed
  reviewCount: 5000,
  avgRating: 4.3
  // full reviews in separate 'reviews' collection
}

Maintaining the Subset With $push and $slice

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.

const newReview = { userId: ObjectId('...'), rating: 5, comment: 'Great product!', date: new Date() }

// Add to main reviews collection
await db.collection('reviews').insertOne({ productId, ...newReview })

// Update subset in product document — keep last 10
await db.collection('products').updateOne(
  { _id: productId },
  {
    $push: {
      recentReviews: {
        $each: [newReview],
        $sort: { date: -1 },
        $slice: 10
      }
    },
    $inc: { reviewCount: 1 }
  }
)

Querying Beyond the Subset

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.

// Fast product page: use embedded subset
const product = await db.collection('products').findOne(
  { _id: productId },
  { projection: { name: 1, price: 1, avgRating: 1, recentReviews: 1 } }
)

// Load more reviews: query the full reviews collection
const moreReviews = await db.collection('reviews')
  .find({ productId })
  .sort({ date: -1 })
  .skip(10)
  .limit(10)
  .toArray()

Comparing Extended Reference and Subset

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.

When NOT to Use These Patterns

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.

Real-World Example: E-Commerce Orders

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.

// Order with Extended Reference — snapshot of address at purchase time
{
  orderId: 'ORD-5678',
  customer: {
    _id: ObjectId('...'),
    name: 'Bob Chen',
    shippingAddress: {
      street: '42 Elm Street',
      city: 'Istanbul',
      country: 'TR'
    }  // snapshot at order time — correct even if customer moves later
  },
  items: [{ sku: 'WGT-001', qty: 2, price: 49.99 }],
  total: 99.98
}

Performance Measurement and Validation

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.

// Measure before and after applying Extended Reference
db.orders.find({ 'customer._id': someId }).explain('executionStats')

// Check average document size after embedding
db.orders.stats().avgObjSize  // in bytes

Quick Check

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

Lesson Recap

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.

Domande Frequenti

La lezione «Pattern Extended Reference e Subset» è gratuita?

Sì — il testo completo di «Pattern Extended Reference e Subset» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso MongoDB Academy, passa a CoddyKit PRO. Il corso MongoDB Academy include 4 lezioni in totale.

Cosa imparerò in «Pattern Extended Reference e Subset»?

I discenti incorporeranno un sottoinsieme selezionato dei campi consultati più frequentemente da un documento referenziato, eliminando le join $lookup nei percorsi di lettura più utilizzati. Eserciti MongoDB Academy con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare MongoDB Academy?

Non è richiesta alcuna esperienza precedente. MongoDB Academy su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 2 di 4.

Quanto tempo richiede la lezione «Pattern Extended Reference e Subset»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione MongoDB Academy?

Sì. Ogni lezione MongoDB Academy include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

← Torna a MongoDB Academy