Amazon DynamoDB Fundamentals

Keys define both identity and efficient access

Amazon DynamoDB is a fully managed serverless key-value and document database. A table contains items, and items contain attributes. Every table has a primary key. A simple primary key uses one partition-key attribute; a composite primary key combines a partition key with a sort key. With a composite key, multiple items can share the partition-key value as long as their sort-key values differ, which lets related items be grouped and ordered within the same key space.

DynamoDB uses the partition-key value as input to an internal hash function that determines where the item is stored. A good partition key therefore serves two jobs: it participates in the application's lookup model and helps distribute traffic across underlying partitions. A key that concentrates a large fraction of requests on a small set of values can create a hot partition even when the table as a whole appears to have enough capacity.

Query is key-directed; Scan examines the table or index

A DynamoDB Query requires a partition-key value and can optionally constrain a sort key. That makes Query a targeted access operation over items that share the specified partition-key value. Results can then be filtered, but a filter expression is applied after the Query has read the matching data; filtering does not reduce the read capacity consumed by the Query itself. If a field must efficiently narrow the data read, it generally belongs in an access pattern supported by a key or index rather than only in a post-read filter.

Scan examines items across a table or secondary index and can apply a filter afterward. This makes Scan useful for some administrative or bounded workloads but usually unsuitable as the main access pattern for a large latency-sensitive application. A data model that continually scans a large table to locate a few records is a strong signal that the key/index design does not match the workload.

• GetItem addresses one item by its primary key.
• Query starts from a partition-key value and can use sort-key conditions to narrow a logical group.
• Filter expressions remove results after data is read; they do not turn a broad read into an efficient key lookup.
• Scan examines a table or index rather than beginning from a single partition-key equality condition.

NoSQL design moves relationships into access patterns

DynamoDB does not ask you to normalize data into many related tables and join them at query time. Instead, an application can denormalize or colocate related items around known keys so its important requests can be served directly. This often means accepting duplication of selected attributes in exchange for predictable access. The right structure is workload-specific rather than a generic conversion of a relational schema.

Distribution is part of correctness at scale. AWS recommends partition keys with enough distinct values to spread activity. DynamoDB adaptive capacity can help uneven access patterns, but it is not a reason to intentionally choose a pathological hot key. Metrics and throttling signals should be monitored so a key design can be revisited before concentrated traffic becomes an application bottleneck.