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!
