C100DEV Data Modeling Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Enable sharding on the readings collection with sensorId as the shard key and store one reading per document.

  Why it's wrong here

  Sharding distributes load across nodes but does not reduce the number of documents or their per-document overhead. Millions of small documents still consume disproportionate storage and index space, and a poorly chosen shard key can create hotspots, so this does not address the core efficiency problem.

• ✗

  Add a compound index on sensorId and timestamp and continue storing one reading per document.

  Why it's wrong here

  A compound index accelerates lookups but does not fix the underlying problem of millions of tiny documents, each carrying per-document overhead such as the _id and field names. Storage remains inefficient and the sheer document count still burdens the query engine, so this is only a partial mitigation.

• ✓

  Use the Bucket Pattern, grouping readings from a sensor for a time window into a single document with an array of measurements.

  Why this is correct

  The Bucket Pattern consolidates many readings into one document per sensor per time window, dramatically cutting document count and per-document overhead. Since queries target a sensor over an hour, a bucket keyed by sensorId and hour aligns perfectly, letting a single document read satisfy the query and reducing index size.

• ✗

  Apply the Attribute Pattern by moving each reading's value into a key-value subdocument.

  Why it's wrong here

  The Attribute Pattern helps when documents have many rarely queried fields that would otherwise create large sparse indexes. Here the fields are few and consistent across readings, so converting values into key-value pairs adds complexity without reducing document count or improving the hourly per-sensor query.