CCNA Mongodb Data Modeling Questions

The Subset Pattern is the best fit because it keeps only the most frequently accessed data (the latest 50 notifications) embedded in the user document while offloading older notifications to another collection. This keeps the document small, avoids hitting the 16MB limit, and ensures fast access to recent notifications without unnecessary complexity.

Referencing is appropriate when a subdocument represents a shared entity that changes independently of its parent. Keeping supplier details in their own collection means one update fixes every product, removes duplicate mutable data, and keeps product documents lean. Indexing the embedded field, versioning the schema, or archiving supplier history all leave the core duplication and mass-update cost in place.

The requirements split into two needs: fast access to recent messages and complete retention of history. Referencing messages in a dedicated collection with an indexed timestamp satisfies retention and efficient recent-message queries, while the Subset Pattern's bounded embedded window gives the fastest possible read for the latest 50. Together they keep conversation documents small and preserve the full message log without hitting the 16MB limit.

The data is stored in buckets, so per-minute analysis requires expanding the embedded array before grouping. $unwind emits one document per array element, and a subsequent $group can bucket by a truncated hour value and compute the average 'close'. This preserves the storage benefits of embedding while still enabling fine-grained aggregation over the measurements.

The Extended Reference Pattern involves copying a small amount of frequently accessed data from a referenced document into the primary document. This allows the application to retrieve the most critical information in a single read, avoiding a join for the majority of use cases. It optimizes for the common case while still allowing the full referenced document to be fetched only when truly needed.

The Subset Pattern is designed to keep the most relevant data in the primary document while moving the bulk of historical data to a separate collection. By storing only the most recent orders in the array, you prevent the document from exceeding the 16MB limit and ensure that high-frequency read operations remain performant, as smaller documents yield better cache utilization in the WiredTiger engine.

The Polymorphic Pattern is designed for collections whose documents share some fields but differ in others. A discriminator like 'category' lets the application and indexes target category-specific attributes while keeping all products queryable in one place. Splitting into multiple collections, flattening to generic key-value pairs, or misapplying schema versioning all sacrifice either query simplicity or schema clarity that this catalog needs.

The Polymorphic pattern stores documents with a shared core plus category-specific fields in one collection. It supports queries across all items using common fields and queries within a category using the discriminator field. This is the natural fit when different document shapes share a meaningful set of fields and are queried together.

In many-to-many relationships, storing arrays of references on both sides (e.g., group_ids in user, user_ids in group) can lead to unbounded arrays if either collection grows large. The most scalable approach is to use a separate 'Membership' collection that stores the mapping between User IDs and Group IDs. This prevents document bloat and allows you to index the relationship in both directions, ensuring optimal performance for all query types.

The Subset Pattern is specifically designed for documents with a large array where only a small portion is accessed regularly. By retaining the frequently used snapshots in the main document and relocating the rest, the document shrinks, the working set fits more easily in RAM, and read-heavy analytics touch far less data while still returning the fields analysts require.

Extended Reference embeds a small set of frequently accessed fields to avoid extra reads, accepting duplication as the cost. Because MongoDB does not synchronize fields across collections, any change to a duplicated field must be written to the source document and to every embedding document. The design is valid and useful, but the application owns consistency.

Managing document growth is critical for long-term stability. The 'subset pattern' keeps only the most relevant items embedded, while 'bucketing' groups related items into separate documents to prevent a single document from growing indefinitely. Both techniques ensure that documents remain performant and well below the 16MB threshold, preventing application crashes when arrays grow beyond predicted sizes over time.

Atomic updates and no-partial-read guarantees come from either keeping related data in one document, where MongoDB's single-document atomicity applies, or wrapping separate documents in a multi-document transaction with snapshot isolation. References and read concern settings do not by themselves provide cross-document atomicity, and capped collections are unrelated to the requirement.

Bucketing readings into fixed-interval documents per device reduces document count and index footprint while keeping queries by device and time range efficient. Because each bucket is bounded, documents remain small and writes spread across buckets over time. The alternatives either multiply documents or create unbounded arrays that risk the size limit.

For a 'One-to-Squillions' relationship, where a parent has a massive, unbounded number of children, neither embedding nor an array of references is viable. Storing the parent ID in the child documents (the 'referencing' pattern) is the only scalable solution. This allows the child documents to be queried efficiently by the parent ID without hitting document size limits or requiring massive updates to the parent document during growth.

Separating medications into their own collection prevents unbounded array growth in patient documents and enables efficient querying with a compound index. The index on `name`, `dosage`, and `patientId` supports queries for patients taking a specific medication with a specific dosage. This design scales well and simplifies management of individual medication records.

Using one collection with a category discriminator and only the fields relevant to each category keeps documents compact and allows targeted indexes on the attributes used in filters. Queries that filter by category and then by category-specific fields are efficient. Padding with nulls, splitting into many collections, or using unpredictable keys all undermine those queries.

Using the Attribute Pattern is the standard MongoDB practice for handling heterogeneous data fields. By restructuring attributes into an array of subdocuments containing 'k' (key) and 'v' (value) fields, you can create a single multikey index on this array. This allows the database to efficiently query across arbitrary product properties without requiring schema changes or thousands of unique collection indexes as requirements evolve over time.

A compound index on `{ genre: 1, author: 1 }` efficiently supports queries that filter on both fields or on `genre` alone, leveraging the index prefix. It also supports sorting by `genre` and `author`, which aligns with common library queries. Single-field indexes may require index intersection, which is less efficient, while text and hashed indexes are unsuitable for exact-match queries.

The Bucket pattern groups multiple related documents (like sensor readings) into a single document representing a time window (e.g., one hour). This significantly reduces the total number of documents in the collection, which improves index efficiency and reduces the memory footprint. By minimizing the index size, the database can keep more of the index in RAM, leading to faster query performance for analytical or time-based data retrieval.

The exhibit shows an array of sub-documents nested directly within a parent document, which is the definition of the embedding pattern. This pattern is used to keep related data together in one physical storage unit. It is highly efficient for read-heavy applications where the parent user record and their order history are almost always required at the same time by the application layer.

The Outlier Pattern is specifically designed to handle documents that grow beyond typical limits due to a few outliers. By embedding only a subset of followers and storing the rest separately, the design keeps the common case fast while accommodating the extreme case. This maintains the ability to quickly show the follower count and first 20 followers without hitting the 16 MB limit.

MongoDB schemas are flexible by design, so a single products collection can hold documents that share common fields and add category-specific ones as needed. This supports one uniform query path indexed on category and price, avoids joins, and lets new categories be introduced without schema migrations. Splitting collections or normalizing into fixed keys adds routing and storage costs that the scenario does not justify.

The polymorphic pattern allows you to store different document structures in the same collection, which is useful when entities share common fields but have unique characteristics. By keeping these in one collection, you simplify queries that need to target the entire entity set and reduce the need for complex application-level logic to manage multiple collections for similar object types, improving developer productivity and consistency.

This is the Attribute pattern. It is used when you need to store documents where fields vary significantly or when you need to index multiple fields that share a common structure. By transforming key-value pairs into an array of sub-documents, you can create a single multikey index on the 'specs.k' and 'specs.v' fields, allowing for efficient queries across diverse attribute sets that would otherwise require too many individual indexes.

Storing thousands of followers in an array within the user profile document is a violation of the unbounded array anti-pattern, as it would cause the document to grow beyond the 16MB limit and result in poor write performance. Referencing the followers in a separate collection, where each follower is a separate document, provides a scalable solution that supports high growth and efficient querying without performance degradation.

The Polymorphic Pattern is the standard MongoDB approach when multiple entity types share some fields and a common query path but differ in their specific attributes. Keeping all products in one collection with shared fields such as name and category-specific fields lets a single indexed query serve the catalog search while preserving each category's natural structure.

The Bucket Pattern is purpose-built for time-series data, grouping measurements into documents keyed by a time window. Because queries retrieve a sensor's readings for a specific hour, a bucket per sensor per hour lets one document serve the query, slashes document count and overhead, and shrinks the index footprint, improving both storage efficiency and read performance.

The Subset Pattern is ideal when a document contains a large array that grows indefinitely. By embedding only the most recent 10 comments, the post document remains small and the application can still fetch the post with its recent comments in one read. Older comments are stored separately, preserving access to historical data without bloating the main document.

The requirement is a frequent read that needs an order plus a few product fields. Embedding just those fields as an extended reference satisfies the query with one document read, and accepting limited duplication is justified because the copied fields change rarely. Together these considerations optimize the common read path without inflating documents with unnecessary product data.

The Computed Pattern is used to store calculated values (like totals, counts, or averages) directly within a document to minimize expensive real-time calculations. This is vital when the cost of computing a result exceeds the cost of updating a stored value. It is particularly effective for read-intensive workloads where the computed result is requested frequently, allowing the application to simply read the pre-calculated value from the document.

Moving likes to their own collection removes the unbounded array from posts and enables indexed per-user lookups, while a denormalized likeCount on the post answers the count question without embedding all likes. Together these keep post documents small and support both required questions. Indexing the array, capped collections, or truncation do not satisfy both goals.

The Subset Pattern is used to prevent documents from growing too large while keeping frequently accessed data local. By embedding only the most important subset of child documents (e.g., the five most recent comments) and referencing the rest, you balance read performance with document size management. This is essential for maintaining consistent performance levels as datasets scale, ensuring that the working set remains efficient for typical user queries.

Migrating from an unbounded embedded array to the Bucket Pattern divides reviews into manageable document chunks based on a count or time threshold. This prevents documents from exceeding the 16MB limit and reduces RAM pressure. Managing growth ensures predictable update performance and maintains indexing efficiency across high-throughput collections in production workloads.

The Outlier Pattern is the correct design when a minority of documents drastically exceed the typical size of the rest. By marking outlier documents and relocating their oversized arrays to a separate collection, developers preserve the simple embedded model for the common case while still supporting celebrity-scale data. Neither subsetting recent entries nor time-bucketing events addresses the real requirement of storing a complete, queryable follower list for every user.

For a field with a limited set of values that is frequently queried, a simple single-field index on that field is the most efficient and straightforward solution. It supports equality matches and aggregation for counting, and it has minimal impact on write performance. More complex patterns or compound indexes are not warranted based on the described access patterns.

The correct design separates the unbounded child data into its own collection and uses bucketing to keep related transactions efficient to query. Referencing the account preserves relational integrity, while monthly buckets cut index size and improve range-scan performance. Capping, compressing, or pushing structured data into GridFS all fail either the completeness requirement or the queryability requirement that auditors demand.

The Computed Pattern is designed to precompute and store aggregated values like total revenue per product. By updating the product document whenever an order is placed, the application avoids expensive aggregation scans during report generation. This pattern is ideal for frequently accessed aggregates and provides fast read performance at the cost of additional write operations.

Keeping a small, bounded embedded array of recent items alongside an unbounded separate collection is a common way to keep the hot working set small and avoid unbounded document growth. The account document stays compact and fast to read, while the full history remains queryable. The other choices describe features MongoDB does not provide through embedding.

Bucketing groups many measurements into a single document, so a fixed time-window query for one device scans a small, predictable number of documents and index keys. Grouping by device and hour keeps buckets bounded in size, avoiding the 16MB limit, while the index on deviceId and startTime supports fast range filtering. The other designs either explode the number of documents or introduce unbounded growth and joins.

The Polymorphic Pattern allows a single collection to store documents with different structures, while the Attribute Pattern converts variable attributes into an indexable array of key-value pairs. Together, they provide a flexible schema that supports efficient queries on any category-specific attribute. Both patterns are widely used in MongoDB for handling heterogeneous data and are appropriate here.

For a one-to-few relationship where the embedded data is small, updated infrequently, and always accessed with the parent document, embedding is the recommended approach. It simplifies queries, ensures atomicity, and provides the best read performance without the overhead of joins or multiple round trips.

The Subset pattern allows you to store the most frequently accessed data in the main document while offloading the rest to another collection. This ensures that the primary document remains small and fits efficiently into the WiredTiger cache, which significantly boosts read performance for common queries. By reducing the overall document size, you also avoid the 16MB BSON limit while still keeping essential information easily accessible for the application's most frequent use cases.

When the referenced set is small and slow-changing, a reference is preferable to embedding because it avoids duplicating data and keeps one authoritative source. The $lookup join is inexpensive for a tiny collection, and the application can cache the whole carrier set, so shipment reads rarely pay join cost. Full denormalization or cross-database joins add complexity without benefit here.

The Attribute Pattern is the standard solution for schemas with heterogeneous fields. By transforming fields into an array of key-value pairs (k: 'color', v: 'red'), you create a uniform structure that allows for single-index coverage across all attributes. This avoids the limitations of sparse indexes and allows the application to query arbitrary attributes without needing to modify the document structure or rebuild large index sets frequently.

The Extended Reference pattern involves copying frequently accessed fields from a referenced document into the current document. This eliminates the need for costly $lookup operations during read queries. It is a vital pattern for high-performance applications where latency is critical, as it trades a small amount of data redundancy for significant gains in read speed by enabling single-document retrieval for complex data views.

When an embedded array can grow without a realistic upper bound, the document risks hitting the 16MB BSON limit and queries become costly because large arrays must be scanned. Modeling the relationship as its own collection with a supporting index keeps documents small, enables efficient pagination, and allows accurate counts using standard aggregation or count operations.

MongoDB automatically creates a multikey index when you index an array field. This allows the query engine to efficiently find documents that contain any of the elements in the array. This index type is highly performant for tag-based filtering because it maps every element in the array to the document location, enabling rapid searches without scanning every document in the collection.

A selective embedding of only the fields commonly shown with orders keeps those reads fast and self-contained, while the authoritative, larger profile stays in its own collection to avoid widespread duplication. This balances read locality with manageable update cost. The other choices either over-duplicate volatile data or force a lookup on every read.

Modeling friendships as separate documents with a compound index on both user fields enables efficient indexed lookups for mutual friends. This design avoids the pitfalls of unbounded arrays and leverages MongoDB's indexing to handle large-scale social graphs, ensuring queries remain performant as the dataset grows.

Embedding is correct for bounded data read together with its parent, so reactions belong inside the post. Referencing is correct for unbounded, independently paginated data, so comments belong in their own collection with an index supporting ordered retrieval by post. The two patterns are applied to the two data sets according to their cardinality and access patterns rather than uniformly.

The primary risk is creating too many 'joins' (lookups) in the application, which leads to slow performance. When you link data across collections, the database must perform extra work to resolve these references. If done too frequently, especially in high-traffic read paths, it creates significant latency and increases the load on the database, which directly undermines the performance benefits usually associated with MongoDB's document-based architecture.

By using the Attribute Pattern with an array of key-value pairs, you can create a single multikey index on the 'specs.k' and 'specs.v' fields. This allows you to query any arbitrary attribute efficiently without having to create a separate index for every possible product specification. This approach provides a flexible, performant way to handle highly variable product schemas that would otherwise require hundreds of individual indexes.