2.1.4.1. DynamoDB Core Concepts: Tables, Items, Attributes
2.1.4.1. DynamoDB Core Concepts: Tables, Items, Attributes
First Principle: DynamoDB's fundamental data model (Tables, Items, Attributes) provides a flexible, schema-less structure enabling developers to manage application state with high scalability and performance.
Understanding the core components of Amazon DynamoDB's data model is essential for designing efficient and scalable applications.
- Tables: (Collections of data.) Similar to tables in relational databases, but without a fixed schema (except for the primary key). You define a table, and then add items to it.
- Items: (A group of attributes that is uniquely identifiable among all of the other items in a table.) Similar to a row in a relational database. Each item in a table must have a unique primary key.
- Attributes: (Fundamental data elements.) Similar to a column in a relational database. DynamoDB is schema-less, meaning items in the same table can have different attributes (except for the primary key attributes, which must be present in every item).
- Primary Key: (Uniquely identifies each item in a table.) Can be a single attribute (Partition Key) or a composite of two attributes (Partition Key + Sort Key).
- Partition Key (Hash Attribute): Determines the logical and physical partitions where data is stored.
- Sort Key (Range Attribute): Defines the order of items within a partition and allows for composite primary keys.
Core operations and expressions:
| Need | Use | Watch out for |
|---|---|---|
| Create / read / update / delete one item | PutItem, GetItem, UpdateItem, DeleteItem | GetItem needs the full primary key; PutItem silently replaces an existing item |
| Insert only if the key is new | PutItem + ConditionExpression attribute_not_exists(pk) | fails with ConditionalCheckFailedException if the item exists |
| Update only if a value is still what you expect | UpdateItem + ConditionExpression | a read-then-write in code can race; the condition is checked atomically |
| Increment a counter safely | UpdateItem with SET c = c + :inc (or ADD) | read-modify-write in code loses updates |
| Items in one partition, optionally a sort-key range | Query + KeyConditionExpression (partition-key equality, optional sort-key condition such as begins_with); add IndexName to query an index | non-key attributes can't go in the key condition — use FilterExpression |
| Items across all partitions | Scan (+ FilterExpression) | reads the whole table; filters apply after the read, so capacity is still consumed |
| Return only some attributes | ProjectionExpression | shrinks the response, not the RCUs consumed |
| Next page (each response caps at 1 MB) | pass LastEvaluatedKey back as ExclusiveStartKey | Limit doesn't lift the 1 MB cap |
| All-or-nothing writes across items or tables | TransactWriteItems | BatchWriteItem is not atomic — some writes can fail |
| Expire items automatically | Time to Live (TTL) on a Number attribute holding an epoch-seconds expiry | deletion runs in the background, typically within a few days of expiry |
Scenario: You're developing a new application that stores user profiles. Each user profile has a unique ID, but you want the flexibility to add different attributes (e.g., email, phone, address) for different users without predefined columns.
⚠️ Exam Trap: Every DynamoDB item can have different attributes (except the primary key) — it's schema-less. But you MUST define the partition key (and optional sort key) at table creation time. You cannot change the primary key after creation.
