DynamoDB - Introduction

DynamoDB allows users to create databases capable of storing and retrieving any amount of data and comes in handy while serving any amount of traffic. It dynamically manages each customer's requests and provides high performance by automatically distributing data and traffic over servers.

• It is a fully managed NoSQL database service that is fast, predictable in terms of performance, and seamlessly scalable.
• It relieves the user from the administrative burdens of operating and scaling a distributed database as the user doesn't have to worry about hardware provisioning, patching Software, or cluster scaling.
• It also eliminates the operational burden and complexity involved in protecting sensitive data by providing encryption at REST.

Core Architecture: Tables, Items, and Attributes

DynamoDB organizes data in a hierarchy:

1. Table: A collection of data. (Equivalent to a Table in SQL).
2. Item: A single record in the table. (Equivalent to a Row in SQL).
3. Attribute: A single data element in an item. (Equivalent to a Column in SQL).

The Primary Key: Partition Key Vs Sort Key

The most critical design decision in DynamoDB is your Primary Key. It determines how data is stored and queried. There are two types:

Partition Key (Simple Primary Key):

• Composed of one attribute (e.g., UserID).
• DynamoDB uses this key to hash and distribute data across physical partitions.
• Constraint: You can only query for an exact match on this key (e.g., GetItem where UserID = 123).

Partition Key + Sort Key (Composite Primary Key):

• Composed of two attributes (e.g., Artist as Partition Key and SongTitle as Sort Key).
• All items with the same Partition Key are stored together physically and sorted by the Sort Key.
• Constraint: Uniqueness is enforced on the combination (Artist + SongTitle).
• Power: This allows rich queries, like "Get all songs by Taylor Swift (Partition) that start with the letter L (Sort)".

Secondary Indexes: LSI Vs GSI

What if you want to query by a field that isn't your primary key (e.g., finding a user by Email instead of UserID)? You use Secondary Indexes.

Note: Most modern applications prefer GSIs because they are more flexible and scalable. LSIs are rarely used in new designs due to their limitations.

Capacity Modes: On-Demand Vs Provisioned

DynamoDB offers two pricing models that dictate how it scales.

Advanced Features

1. DynamoDB Streams

• A time-ordered flow of information about item changes in a table. When you enable Streams, every insert, update, or delete is recorded.
• Use Case: Trigger an AWS Lambda function every time a new user signs up (Insert) to send a welcome email, or replicate data to OpenSearch for full-text search.

2. Global Tables

• Fully managed, multi-region replication.
• Active-Active: You can write to the table in us-east-1 and eu-west-1 simultaneously. DynamoDB handles the conflict resolution and replication (typically in < 1 second).
• Use Case: Apps requiring 99.999% availability and low latency for users worldwide.

3. DynamoDB Accelerator (DAX)

• A fully managed, in-memory cache for DynamoDB.
• Performance: Reduces response times from milliseconds to microseconds.
• Use Case: Read-heavy workloads like gaming leaderboards or real-time bidding.

DynamoDB Vs RDBMS: A Quick Comparison

Limitations of DynamoDB

The below list provides us with the limitations of Amazon DynamoDB: 

• It has a low read capacity unit of 4kB per second and a write capacity unit of 1KB per second.
• All tables and global secondary indexes must have a minimum of one read and one write capacity unit.
• Table sizes have no limits, but accounts have a 256 table limit unless you request a higher cap.
• Only Five local and twenty global secondary (default quota) indexes per table are permitted.
• DynamoDB does not prevent the use of reserved words as names.
• Partition key length and value minimum length sits at 1 byte, and maximum at 2048 bytes, however, DynamoDB places no limit on values.