Amazon DynamoDB

Pratheesh Jayakumar 18/04/2023

Introduction to Cloud Databases

• Accessed and Managed over internet – AWS

• Scalability, Flexibility, Reliability

• Cost effective

• RDS, ElastiCache, DynamoDB

DynamoDB Basics

• Table

• Items – Row or Record in DBMS

• Primary Key – Unique Identifier

• Attributes – Columns ( Not structured )

Primary Key
BankAccount
AccountNumber (PK) IFSCCode (SK) Attributes

123312477 0002027213 Personal: { ‘Type’: ‘Savings’, ‘Balance’: 1000, ‘Salaried’: ‘Y’,

‘Name’: ‘Sooriya’ },
Loan: { ‘Id’: 1, ‘Car’: ‘Venue’, ‘Amount’: 0}
32789088 0002027213 Personal: { ‘Type’: ‘Current’ , ‘Balance’: 6583, ‘Salaried’:
‘N’, ‘Name’: ‘Shyam’}

Composite Primary Key

> Partition Key (Unique) + Sort Key (Grouping)

> Improved efficiency of data retrieval

From SQL to NoSQL

• Goals
˃ Why do we need to move away from SQL

• Choices
˃ What do we need to do to move away from SQL?

• Implications
˃ How do we move away from SQL?
From SQL to NoSQL

• Goals

> Consistency – O(1) , Reduce need for Expertise

> Predictability – Performance, Estimate Cost

> Reliability – Fully Managed, Reduced Downtime

From SQL to NoSQL

• Choices

> Importance of Primary Keys

> Clear, Harsh Limits

> No Joins & Aggregations

From SQL to NoSQL

• Importance of Primary Keys

P1 P2 P3
> Partition and Sort Keys
):
be r
tN um
n
o Request Router (Regional) PutItem : Accou
fx (
AccountNumber: 12331..
AccountType: ‘Savings’

o Needed for all operations

(Except Scan)

o Constant fetch time (O(1)) as P4 P5 P6

partitions are known
From SQL to NoSQL

• Clear, Harsh Limits

P1 P2 P3
> Query + Scan : 1MB Page Limit
):
be r
tN um
n
cou
> Pagination Tokens PutItem :
AccountNumber: 12331.. fx ( Ac

Balance: 1500

> Partition throughput : 1K

WCU/s and 3K RCU/s
P4 P5 P6
> No Joins and Aggregations
From SQL to NoSQL

• Implications

> Hard work upfront – Design for Access Pattern, Maintain Aggregations,
Pagination and Sorting, Sharding (Split most used Partitions)

> Use Secondary Indexes (GSI) – Copy of base Table with new PK, Can be
Queried/Scanned, Can’t be updated

> Generic Primary Keys – Single Table Design, Complex Data Structures

> Denormalization – Complex Attributes, Duplication of Data improves

Performance
Example
BankAccount
AccountNumber (PK) IFSCCode (SK) Attributes
123312477 0002027213 Personal: { ‘Type’: ‘Savings’, ‘Balance’: 1000, ‘Salaried’: ‘Y’,
‘Name’: ‘Sooriya’ },
Loan: { ‘Id’: 1, ‘Car’: ‘Venue’, ‘Amount’: 0} , Loan: {‘Id’: 2,
‘Home’: ‘Mogappair’, ‘Amount:’ 0 }
32789088 0002027213 Personal: { ‘Type’: ‘Current’ , ‘Balance’: 6583, ‘Salaried’:
‘N’, ‘Name’: ‘Shyam’},
Loan: {‘Id: 3, ‘Car’: ‘Creta’, ‘Amount’: 100000}

Loan: { ‘Car’: ‘Y’, ‘Amount’: 4000 }

GSI
IFSCCode (GPK) LoanId(GSK) Attributes
0002027213 1 Loan: {‘Car’: ‘Venue’, ‘Amount’: 0},
0002027213 2 Loan: {‘Home’: ‘Mogappair’, ‘Amount’: 0}
0002027213 3 Loan: {‘Car’: ‘Creta’, ‘Amount’: 100000}
Revisiting Primary Keys

• Split Item into Indexing Attributes and Application Attributes

• Partition Key must be having high Cardinality (Vital information)

• Maintain uniqueness (Avoid meaningless random IDs)

• Primary Key cannot be changed – Use Secondary Index for mutable

Primary Key
Write Operations

• Start modeling data with Write patterns

> Primary Key is a must for all Insert/Updates operations

> Maximize usage of Main Table, not Secondary Index

> Consider Unique constraints for updation in GSI

Write Operations

• Maintaining Constraints

> Conditional Expression (Single Items) – Duplicate PK, Attribute Restrictions

> Transactions (For Multiple Items) – Based on another Item

Summary

• DynamoDB Basics

• From SQL to NoSQL

• Primary Keys

• Write Operations
Thank you!