DynamoDB

Mohammed Riyad El Khoudary

Database Modeling
• How to represent your data. Designing the Database Schema

• How to read your data. Querying and Scanning Data

• How to write your data. Inserting, Updating, and Deleting Data

Relational Design Pattern
• How to represent your data. Relational Tables with Joins

• How to read your data. Using the Mighty SQL

• How to write your data. Using the Mighty SQL

Relational Design Pattern
• You design your schema.

• You normalize your schema.

• You are ready to go!

• Access it the way you need… and it always fits!

Relational is Excellent! But…
• Joins are expensive and don’t necessarily age well.

• Higher performance requires deeper knowledge.

• Can easily become a bottleneck microservices and lambdas.

Relational and Lower-Level Problems
• Locks on multiple tables.

• Large rows and page reads.

• Complex queries and full table scans.

• Expensive scaling.

• Of course, there are solution! but they’re also not that simple!
Now.. Is NoSQL a Model?
• NoSQL is simple “NOT” Relational.

• Each engine is COMPLETELY different from the other.

• It’s not like Oracle, MySQL, SQL Server to Relational.

• You don’t have the same De facto standard cover here.

• You need to work harder on your understanding.

DynamoDB
• Fully Managed NoSQL Database Service.

• Supports simple Key-Value to complex Items.

• Promises Fast, Predictable Performance, and Seamless Scalability.

• Offloads you from administrative burdens.

• Automatically replicated, built-in highly available.

DynamoDB Modeling Strategy
• Learn about Cost Model and Service Limits.

• Learn the Basic Concepts.

• Target Reducing Cost as you go.

• You will get what you were promised!

Speed High Performance Seamless Scalability

DynamoDB Service Limits
• Read Capacity Unit (RCU):
One consistent read per second or Two eventually consistent reads
per second up to 4 KB in size.

• Write Capacity Unit (WCU):

One write per second up to 1 KB in size.

• Table Size is Practically Unlimited

DynamoDB Table Structure
• Primary Key
• Partition Key
• Sort Key optional

• Item
• Attributes Number, String, Binary, Boolean, Null, List, Map, Set
DynamoDB Table Structure

Partition Key Attributes

Partition Key Sort Key Attributes

DynamoDB Table Structure
• Customers
Customer Details
Customer ID
First Name Last Name Age Address
USER-000001 Mohammed El Khoudary 39 Al Nasr Street

• Sensor Readings
Reading Details
Sensor ID Timestamp
First Name Signal Strength Width
2023-10-20T13:15:12 13 12 11
SENSOR-0001
2023-10-20T13:15:15 15 13 10
 DynamoDB Table Structure
Operators Access
Direct Access =, !=, >, <, Begins With

Partition Key Sort Key Attributes

Result Goes Ascending or Descending

Result can be limited to n Items
You pay for what you read
DynamoDB Modeling Strategy
• Don’t use DynamoDB as Relational DB without Joins!

• Learn the difference between:

Scan Query GetItems
• Simple math:
GetItems for 100 items 10 bytes each will cost you 100 RCU.
Query for same 100 items 10 bytes each will cost you 1 RCU.

• People misuse tools and then they say ITS EXPENSIVE!

DynamoDB Single Table Model
• Use one table for multiple entities.
PK SK Attributes
Name Age Eye Color
customer#details
Mohammed 39 Brown
CUSTOMER#0001
Q1 Q2
customer#poll
Y N

Id Date
order#details
12433 12/11/2023
Order#0001
Item Qty
order#lineItem#1
TV 3
DynamoDB Single Table Model???
• You Overload Partition Key and Sort Key.

• You read different related data using One Query.

• You vertically partition your data to read/write smaller chunks.

• E.g. to read all order line items you query Order#0001 partition and
sort key Begins With order#lineItem#.
DynamoDB – Vertical Partitioning
• Instead of stuffing all your data in one item.

• Partition that data vertically using sort keys.

• Reduce cost when reading/querying/writing items.

• And with cost reduction comes higher throughput.

DynamoDB Single Table Model???!!!!!
• That’s Pretty Complex!

• But it can replace transactional part in huge systems.

• And it solves most of the scalability problems mentioned before.

“well-optimized single-table DynamoDB layout looks more like machine

code than a simple spreadsheet”
DynamoDB – Approaching Good Design
• Create your ERD, Layout your Entities and their relations.

• Write down your access patterns, read and write.

• Proceed stuffing the entities into a single DynamoDB table using keys
overloading.

• Evolve the design to serve the access patterns with the least RCU and
WCU possible.
DynamoDB – Example
DynamoDB – Example – Access Patterns

1. Get movie by movie ID

2. List cast of a movie
3. Get movies by an actor - GSI
4. Get actor by actor ID - GSI
DynamoDB – Example
DynamoDB – More Access Patterns
• LSI – Local Secondary Indexes.

• GSI – Global Secondary Indexes.

• Sparse Indexes.
GSI
PK SK Attributes
To
Invoice#Details
Mohammed
Invoice#0001
Amount
Bill#0001
150

To
Invoice#Details
Sameer
Invoice#0002
Amount
Bill#0001
130
GSI
PK – GSI SK SK – GSI PK Attributes
Amount All Bill Invoices
Invoice#0001
Can be Read in a Single Query
150
Bill#0001
Amount
Invoice#0002
130

To
Invoice#0001
Mohammed
Invoice#Details
To
Invoice#0002 All Invoices Details
Sameer Can be Read in a Single Query
DynamoDB has More to Offer
• TTL – as a free way to delete data.

• DynamoDB Streams.
Single Table Design Disadvantages?
• Steep learning curve.

• Inflexibility to add new access patterns.

• Exporting for analytics requires more work.

• Elevated complexity.
DynamoDB, how to begin?
• You can have the NoSQL Workbench.

• It comes with a locally hosted DynamoDB testing platform.

• You need to take the approach into action.

• Results are guaranteed to achieve goals if guidelines are properly

followed.
Finally,
Gaining knowledge opens closed doors
the same way money does.

Maybe more than money does..

Sometimes…