A developer stores IoT sensor readings in a DynamoDB table. The primary access pattern is to retrieve every reading for one sensor within a given time range, ordered by timestamp. Each sensor produces thousands of readings per day across millions of sensors. How should the developer model the table's primary key?
- AUse the timestamp as the partition key and the sensorId as the sort key so readings sort by time within each second.
- BUse a single fixed string as the partition key and the sensorId as the sort key so all items share one partition for fast Query.
- CUse a random GUID as the partition key and store sensorId and timestamp as plain non-key attributes for later filtering.
- DUse the sensorId as the partition key and the timestamp as the sort key so each sensor's readings are stored together and sortable. Correct
Why A is wrong: A timestamp partition key spreads one sensor's readings across many partitions, so a single Query cannot return one sensor's range efficiently and creates hot partitions at write time.
Why B is wrong: A single fixed partition key concentrates every write and read on one partition, which throttles badly and defeats DynamoDB's horizontal scaling under high request volume.
Why C is wrong: A random GUID partition key spreads writes well but makes the required per-sensor time-range read impossible without a costly full Scan and filter expression.
Why D is correct: A high-cardinality sensorId partition key spreads load evenly, and the timestamp sort key lets one Query return a contiguous time range for a single sensor in order.