Amazon DynamoDB is a fully managed NoSQL database service that provides fast and predictable performance with seamless scalability. DynamoDB lets you offload the administrative burdens of operating and scaling a distributed database so that you don't have to worry about hardware provisioning, setup and configuration, replication, software patching, or cluster scaling. DynamoDB also offers encryption at rest, which eliminates the operational burden and complexity involved in protecting sensitive data.
DynamoDB provides on-demand backup capability. It allows you to create full backups of your tables for long-term retention and archival for regulatory compliance needs.
It is ideal for applications requiring consistent, single-digit millisecond response times. DynamoDB supports key-value and document data models, making it versatile for various use cases such as gaming, IoT, and mobile apps.
You can create on-demand backups and enable point-in-time recovery for your Amazon DynamoDB tables. Point-in-time recovery helps protect your tables from accidental write or delete operations. With point-in-time recovery, you can restore a table to any point in time during the last 35 days.
Key Features
High Availability and Durability:
Geographically Distributed Replicas: DynamoDB stores three replicas of each table, distributed across three Availability Zones (AZs) within an AWS region.
Synchronous Replication: Data is synchronously replicated across these three AZs, ensuring high availability and data durability.
Serverless Architecture:
No Server Management: DynamoDB is a serverless service, eliminating the need to provision, patch, or manage servers.
Push-Button Scaling: Easily scale up or down without any downtime. Amazon DynamoDB auto scaling uses the AWS Application Auto Scaling service to dynamically adjust provisioned throughput capacity on your behalf, in response to actual traffic patterns. This is the most efficient and cost-effective solution to optimizing for cost.
Data Model:
Schema-Less: DynamoDB is schema-less, allowing flexible data structures.
Tables, Items, and Attributes:
Tables – Similar to other database systems, DynamoDB stores data in tables. A table is a collection of data. For example, see the example table called People that you could use to store personal contact information about friends, family, or anyone else of interest. You could also have a Cars table to store information about vehicles that people drive.
Items – Each table contains zero or more items. An item is a group of attributes that is uniquely identifiable among all of the other items. In a People table, each item represents a person. For a Cars table, each item represents one vehicle. Items in DynamoDB are similar in many ways to rows, records, or tuples in other database systems. In DynamoDB, there is no limit to the number of items you can store in a table.
Attributes – Each item is composed of one or more attributes. An attribute is a fundamental data element, something that does not need to be broken down any further. For example, an item in a People table contains attributes called PersonID, LastName, FirstName, and so on. For a Department table, an item might have attributes such as DepartmentID, Name, Manager, and so on. Attributes in DynamoDB are similar in many ways to fields or columns in other database systems.
Storage:
SSD Storage: Data is stored on fast SSD storage.
Item Size Limit: The aggregate size of an item, including keys and all attributes, cannot exceed 400KB. Pointers to larger objects stored in S3 can be included.
Data Structures:
Key-Value: Data stored as key-value pairs, with keys serving as unique identifiers.
Document: Supports JSON, HTML, and XML documents.
Low Latency:
Very Low Latency: Provides single-digit millisecond latency for read and write operations.
Multi-AZ and Cross-Region:
Multi-AZ Redundancy: Ensures high availability within a region.
Cross-Region Replication: Optional feature to replicate data across regions for disaster recovery and global distribution.
Access Control
IAM Integration:
Identity-Based Policies: Attach permissions policies to users, groups, or roles to control access.
User/Group Policies: Manage permissions at the user or group level.
Role-Based Policies: Grant cross-account permissions through roles.
Resource-Based Policies: DynamoDB does not support resource-based policies.
IAM Conditions: Use IAM conditions to restrict user access to their own records.
Resources and Subresources:
Primary Resources: Tables are the primary resources.
Additional Resource Types: Includes indexes and streams, which are subresources created in the context of existing tables.
Use Cases
Session State Data: Ideal for storing session state data due to its low latency and high availability.
High Traffic Web Applications: Supports applications requiring high request rates.
IoT and Mobile Apps: Suitable for applications with variable and high traffic patterns.
These resources and subresources have unique Amazon Resource Names (ARNs) associated with them, as shown in the following table.
A partition is an allocation of storage for a table that is automatically replicated across multiple AZs within an AWS Region.
Partition management is handled entirely by DynamoDB—you never have to manage partitions yourself.
DynamoDB allocates sufficient partitions to your table so that it can handle your provisioned throughput requirements.
DynamoDB allocates additional partitions to a table in the following situations:
If you increase the table’s provisioned throughput settings beyond what the existing partitions can support.
If an existing partition fills to capacity and more storage space is required.
Primary Keys
DynamoDB stores and retrieves data based on a Primary key.
It supports two different kinds of primary keys:
Partition key – A simple primary key, composed of one attribute known as the partition key.
DynamoDB uses the partition key's value as input to an internal hash function. The output from the hash function determines the partition (physical storage internal to DynamoDB) in which the item will be stored.
In a table that has only a partition key, no two items can have the same partition key value.
Partition key and sort key – Referred to as a composite primary key, this type of key is composed of two attributes. The first attribute is the partition key, and the second attribute is the sort key.
DynamoDB uses the partition key value as input to an internal hash function. The output from the hash function determines the partition (physical storage internal to DynamoDB) in which the item will be stored. All items with the same partition key value are stored together, in sorted order by sort key value.
In a table that has a partition key and a sort key, it's possible for multiple items to have the same partition key value. However, those items must have different sort key values.
Secondary indexes
You can create one or more secondary indexes on a table. A secondary index lets you query the data in the table using an alternate key, in addition to queries against the primary key. DynamoDB doesn't require that you use indexes, but they give your applications more flexibility when querying your data. After you create a secondary index on a table, you can read data from the index in much the same way as you do from the table.
DynamoDB supports two kinds of indexes:
Global secondary index – An index with a partition key and sort key that can be different from those on the table.
Local secondary index – An index that has the same partition key as the table, but a different sort key.
In DynamoDB, global secondary indexes (GSIs) are indexes that span the entire table, allowing you to query across all partition keys. Local secondary indexes (LSIs) are indexes that have the same partition key as the base table but a different sort key.
Each table in DynamoDB has a quota of 20 global secondary indexes (default quota) and 5 local secondary indexes.
Example:
In the example Music table shown below, you can query data items by Artist (partition key) or by Artist and SongTitle (partition key and sort key). What if you also wanted to query the data by Genre and AlbumTitle? To do this, you could create an index on Genre and AlbumTitle, and then query the index in much the same way as you'd query the Music table.
The following diagram shows the example Music table, with a new index called GenreAlbumTitle. In the index, Genre is the partition key and AlbumTitle is the sort key.