Introduction
Amazon DynamoDB is a fully managed NoSQL database service. The term NoSQL describes a family of databases in which data is not required to be stored in the related tables of the traditional relational model, and in which access is typically performed by key rather than through the SQL query language. The term fully managed means that the servers, patching, scaling, and backups are handled by AWS. This guide explains what DynamoDB is, why it exists, how data is stored and retrieved, and the situations in which it is appropriate.
What is it?
DynamoDB stores data as items inside tables. A table is a collection of items. An item is a single record, similar to a row in a spreadsheet. An attribute is a single field within an item, similar to a column. Unlike a relational database, items in the same table are not required to share the same attributes, which allows a flexible structure. Performance remains consistent, typically within single-digit milliseconds, regardless of how large a table becomes.
Why does it exist?
Relational databases are well suited to complex queries, but they are difficult to scale across many servers while maintaining consistent performance. As traffic grows, careful tuning is often required, and performance can become unpredictable. DynamoDB was created so that a database could scale to very large volumes of data and traffic while performance remained steady and predictable. Capacity is managed by AWS, and the developer is freed from the operational work of running database servers.
How it works
Every item is identified by a primary key, which is the value that uniquely identifies it. The primary key is built from a partition key, and optionally a sort key. A partition key determines the physical partition in which an item is stored, which allows data to be distributed evenly. A partition is a unit of storage and throughput. A sort key orders the items that share the same partition key, which allows a range of related items to be retrieved together in a single, efficient operation.
Additional access patterns are supported through secondary indexes. A global secondary index allows items to be queried by an attribute other than the primary key. Throughput is managed through one of two capacity modes. In on-demand mode, each read and write is charged individually and no planning is required. In provisioned mode, a fixed level of throughput is reserved in advance. Reads may be served with eventual consistency, in which a recently written value may briefly be out of date, or with strong consistency, in which the most recent value is always returned.
Architecture diagram
Advantages
- Predictable performance. Response times remain consistent as data and traffic grow.
- Automatic scaling. Storage and throughput expand without servers being managed.
- Fully managed. Patching, replication, and backups are handled by AWS.
- Event integration. Changes can be streamed to trigger other services such as Lambda.
- High availability. Data is replicated across multiple facilities automatically.
Disadvantages
- Limited query flexibility. Access must be planned around keys and indexes, and ad-hoc queries are not well supported.
- No joins. Relationships that would be joined in a relational database must be modeled differently.
- Design effort. Effective use requires the access patterns to be understood before the table is designed.
- Cost of misuse. Full-table scans and poorly chosen keys can become expensive.
Common use cases
- Serverless application data, in which items are read and written by Lambda functions.
- High-traffic workloads such as session stores, shopping carts, and user profiles.
- Applications that require consistent low latency at large scale.
- Event-driven systems, in which changes are streamed to downstream services.
Best practices
- The access patterns should be identified before the table is designed, because the key structure follows from them.
- The partition key should be chosen so that traffic is spread evenly and no single partition is overloaded.
- Secondary indexes should be created for the additional ways in which data must be queried.
- Scans should be avoided in favor of targeted queries by key.
- On-demand capacity should be used for unpredictable traffic, and provisioned capacity for steady, predictable traffic.
Common mistakes
- A relational design is applied to DynamoDB, which leads to inefficient access.
- A partition key is chosen that concentrates traffic on a small number of partitions.
- Scans are used routinely, which increases cost and latency.
- Required access patterns are discovered after the table is in use, when changing the key structure is difficult.
Related AWS services
- AWS Lambda reads from and writes to DynamoDB and can be triggered by table changes.
- Amazon API Gateway exposes the data in DynamoDB through an API.
- DynamoDB Streams emit a record of every change so that other services can react.
- Amazon CloudWatch reports the throughput and errors of a table.
Frequently Asked Questions
- Is DynamoDB a relational database?
- No. DynamoDB is a NoSQL database. Data is organized as items that are retrieved by key rather than as rows in related tables that are queried with SQL. This allows predictable performance at large scale, but it does not provide the joins of a relational database.
- What is the difference between a partition key and a sort key?
- A partition key determines the partition in which an item is stored. A sort key orders the items that share the same partition key, which allows a range of related items to be retrieved efficiently. Together they form the primary key that uniquely identifies an item.
- What is the difference between on-demand and provisioned capacity?
- On-demand capacity charges for each read and write and requires no planning. Provisioned capacity reserves a fixed throughput in advance and can be less expensive for predictable workloads.
- What is the difference between eventual and strong consistency?
- With eventual consistency, a read may briefly return a slightly out-of-date value after a write. With strong consistency, a read always returns the most recent value, at the cost of additional read capacity.
- Why should scans be avoided?
- A scan reads every item in a table, which is slow and expensive at scale. Access should instead be designed around keys and indexes so that only the required items are read.
This article is the summary. The book is the full, continuously updated reference: data modeling, single-table design, capacity planning, and complete serverless architectures.
View the book