This document provides an overview and agenda for a presentation on Amazon DynamoDB. It discusses key concepts like tables, data types, partitioning, indexing and scaling in DynamoDB. It also provides best practices and examples for modeling different data scenarios like event logging, product catalogs, messaging apps and multiplayer games.
2. Agenda
• Tables, API, data types, indexes
• Scaling
• Data modeling
• Scenarios and best practices
• DynamoDB Streams
• Reference architecture
3. Amazon DynamoDB
• Managed NoSQL database service
• Supports both document and key-value data models
• Highly scalable
• Consistent, single-digit millisecond latency at any
scale
• Highly available—3x replication
• Simple and powerful API
7. Data types
• String (S)
• Number (N)
• Binary (B)
• String Set (SS)
• Number Set (NS)
• Binary Set (BS)
• Boolean (BOOL)
• Null (NULL)
• List (L)
• Map (M)
Used for storing nested JSON documents
8. 00 55 A954 AA FF
Partition table
• Partition key uniquely identifies an item
• Partition key is used for building an unordered hash index
• Table can be partitioned for scale
00 FF
Id = 1
Name = Jim
Hash (1) = 7B
Id = 2
Name = Andy
Dept = Engg
Hash (2) = 48
Id = 3
Name = Kim
Dept = Ops
Hash (3) = CD
Key Space
9. Partitions are three-way replicated
Id = 2
Name = Andy
Dept = Engg
Id = 3
Name = Kim
Dept = Ops
Id = 1
Name = Jim
Id = 2
Name = Andy
Dept = Engg
Id = 3
Name = Kim
Dept = Ops
Id = 1
Name = Jim
Id = 2
Name = Andy
Dept = Engg
Id = 3
Name = Kim
Dept = Ops
Id = 1
Name = Jim
Replica 1
Replica 2
Replica 3
Partition 1 Partition 2 Partition N
10. Partition-sort key table
• Partition key and sort key together uniquely identify an Item
• Within unordered partition key-space, data is sorted by the sort key
• No limit on the number of items (∞) per partition key
– Except if you have local secondary indexes
00:0 FF:∞
Hash (2) = 48
Customer# = 2
Order# = 10
Item = Pen
Customer# = 2
Order# = 11
Item = Shoes
Customer# = 1
Order# = 10
Item = Toy
Customer# = 1
Order# = 11
Item = Boots
Hash (1) = 7B
Customer# = 3
Order# = 10
Item = Book
Customer# = 3
Order# = 11
Item = Paper
Hash (3) = CD
55 A9:∞54:∞ AA
Partition 1 Partition 2 Partition 3
15. Scaling
• Throughput
– Provision any amount of throughput to a table
• Size
– Add any number of items to a table
• Max item size is 400 KB
• LSIs limit the number of items due to 10 GB limit
• Scaling is achieved through partitioning
16. Throughput
• Provisioned at the table level
– Write capacity units (WCUs) are measured in 1 KB per second
– Read capacity units (RCUs) are measured in 4 KB per second
• RCUs measure strictly consistent reads
• Eventually consistent reads cost 1/2 of consistent reads
• Read and write throughput limits are
independent
WCURCU
17. Getting the most out of DynamoDB throughput
“To get the most out of
DynamoDB throughput, create
tables where the partition key
has a large number of distinct
values, and values are
requested fairly uniformly, as
randomly as possible.”
—DynamoDB Developer Guide
1. Key Choice: High key
cardinality
2. Uniform Access: access is
evenly spread over the
key-space
3. Time: requests arrive
evenly spaced in time
22. Burst capacity may not be sufficient
0
400
800
1200
1600
CapacityUnits
Time
Provisioned Consumed Attempted
Throttled requests
Don’t completely depend on burst capacity… provision sufficient throughput
Burst: 300 seconds
(1200 × 300 = 360k CU)
23. What causes throttling?
• If sustained throughput goes beyond
provisioned throughput per partition
• From the example before:
– Table created with 5000 RCUs, 500 WCUs
– RCUs per partition = 1666.67
– WCUs per partition = 166.67
– If sustained throughput > (1666 RCUs or 166 WCUs) per key or
partition, DynamoDB may throttle requests
• Solution: Increase provisioned throughput
24. What causes throttling?
• Non-uniform workloads
– Hot keys/hot partitions
– Very large bursts
• Dilution of throughout across partitions caused
by mixing hot data with cold data
– Use a table per time period for storing time series data so WCUs
and RCUs are applied to the hot data set
26. 1:1 relationships or key-values
• Use a table or GSI with a partition key
• Use GetItem or BatchGetItem API
Example: Given a user or email, get attributes
Users Table
Partition key Attributes
UserId = bob Email = bob@gmail.com, JoinDate = 2011-11-15
UserId = fred Email = fred@yahoo.com, JoinDate = 2011-12-01
Users-Email-GSI
Partition key Attributes
Email = bob@gmail.com UserId = bob, JoinDate = 2011-11-15
Email = fred@yahoo.com UserId = fred, JoinDate = 2011-12-01
27. 1:N relationships or parent-children
• Use a table or GSI with partition and sort key
• Use Query API
Example: Given a device, find all readings
between epoch X, Y
Device-measurements
Part. Key Sort key Attributes
DeviceId = 1 epoch = 5513A97C Temperature = 30, pressure = 90
DeviceId = 1 epoch = 5513A9DB Temperature = 30, pressure = 90
28. N:M relationships
• Use a table and GSI with partition and sort key
elements switched
• Use Query API
Example: Given a user, find all games. Or given a
game, find all users.
User-Games-Table
Part. Key Sort key
UserId = bob GameId = Game1
UserId = fred GameId = Game2
UserId = bob GameId = Game3
Game-Users-GSI
Part. Key Sort key
GameId = Game1 UserId = bob
GameId = Game2 UserId = fred
GameId = Game3 UserId = bob
29. Documents (JSON)
• Data types (M, L, BOOL, NULL)
introduced to support JSON
• Document SDKs
– Simple programming model
– Conversion to/from JSON
– Java, JavaScript, Ruby, .NET
• Cannot create an Index on
elements of a JSON object
stored in Map
– They need to be modeled as top-
level table attributes to be used in
LSIs and GSIs
• Set, Map, and List have no
element limit but depth is 32
levels
Javascript DynamoDB
string S
number N
boolean BOOL
null NULL
array L
object M
30. Rich expressions
• Projection expression
– Query/Get/Scan: ProductReviews.FiveStar[0]
• Filter expression
– Query/Scan: #V > :num (#V is a place holder for keyword VIEWS)
• Conditional expression
– Put/Update/DeleteItem: attribute_not_exists (#pr.FiveStar)
• Update expression
– UpdateItem: set Replies = Replies + :num
33. Time series tables
Events_table_2015_April
Event_id
(Partition key)
Timestamp
(sort key)
Attribute1 …. Attribute N
Events_table_2015_March
Event_id
(Partition key)
Timestamp
(sort key)
Attribute1 …. Attribute N
Events_table_2015_Feburary
Event_id
(Partition key)
Timestamp
(sort key)
Attribute1 …. Attribute N
Events_table_2015_January
Event_id
(Partition key)
Timestamp
(sort key)
Attribute1 …. Attribute N
RCUs = 1000
WCUs = 100
RCUs = 10000
WCUs = 10000
RCUs = 100
WCUs = 1
RCUs = 10
WCUs = 1
Current table
Older tables
HotdataColddata
Don’t mix hot and cold data; archive cold data to Amazon S3
34. Use a table per time period
• Pre-create daily, weekly, monthly tables
• Provision required throughput for current table
• Writes go to the current table
• Turn off (or reduce) throughput for older tables
Dealing with time series data
41. Messages
Table
Messages App
David
SELECT *
FROM Messages
WHERE Recipient='David'
LIMIT 50
ORDER BY Date DESC
Inbox
SELECT *
FROM Messages
WHERE Sender ='David'
LIMIT 50
ORDER BY Date DESC
Outbox
42. Recipient Date Sender Message
David 2014-10-02 Bob …
… 48 more messages for David …
David 2014-10-03 Alice …
Alice 2014-09-28 Bob …
Alice 2014-10-01 Carol …
Large and small attributes mixed
(Many more messages)
David
Messages Table
50 items × 256 KB each
Large message bodies
Attachments
SELECT *
FROM Messages
WHERE Recipient='David'
LIMIT 50
ORDER BY Date DESC
Inbox
43. Computing inbox query cost
Items evaluated by query
Average item size
Conversion ratio
Eventually consistent reads
44. Recipient Date Sender Subject MsgId
David 2014-10-02 Bob Hi!… afed
David 2014-10-03 Alice RE: The… 3kf8
Alice 2014-09-28 Bob FW: Ok… 9d2b
Alice 2014-10-01 Carol Hi!... ct7r
Separate the bulk data
Inbox-GSI Messages Table
MsgId Body
9d2b …
3kf8 …
ct7r …
afed …
David
1. Query Inbox-GSI: 1 RCU
2. BatchGetItem Messages: 1600 RCU
(50 separate items at 256 KB)
(50 sequential items at 128 bytes)
Uniformly distributes large item reads
49. • Reduce one-to-many item sizes
• Configure secondary index projections
• Use GSIs to model M:N relationship
between sender and recipient
Distribute large items
Querying many large items at
once
InboxMessagesOutbox
51. GameId Date Host Opponent Status
d9bl3 2014-10-02 David Alice DONE
72f49 2014-09-30 Alice Bob PENDING
o2pnb 2014-10-08 Bob Carol IN_PROGRESS
b932s 2014-10-03 Carol Bob PENDING
ef9ca 2014-10-03 David Bob IN_PROGRESS
Games Table
Multiplayer online game data
52. Query for incoming game requests
• DynamoDB indexes provide partition and sort key
• What about queries for two equalities and a sort?
SELECT * FROM Game
WHERE Opponent='Bob‘
AND Status=‘PENDING'
ORDER BY Date DESC
(partition)
(sort)
(???)
53. Secondary Index
Opponent Date GameId Status Host
Alice 2014-10-02 d9bl3 DONE David
Carol 2014-10-08 o2pnb IN_PROGRESS Bob
Bob 2014-09-30 72f49 PENDING Alice
Bob 2014-10-03 b932s PENDING Carol
Bob 2014-10-03 ef9ca IN_PROGRESS David
Approach 1: Query filter
Bob
54. Secondary Index
Approach 1: Query filter
Bob
Opponent Date GameId Status Host
Alice 2014-10-02 d9bl3 DONE David
Carol 2014-10-08 o2pnb IN_PROGRESS Bob
Bob 2014-09-30 72f49 PENDING Alice
Bob 2014-10-03 b932s PENDING Carol
Bob 2014-10-03 ef9ca IN_PROGRESS David
SELECT * FROM Game
WHERE Opponent='Bob'
ORDER BY Date DESC
FILTER ON Status='PENDING'
(filtered out)
56. • Send back less data “on the wire”
• Simplify application code
• Simple SQL-like expressions
– AND, OR, NOT, ()
Use query filter
Your index isn’t entirely selective
58. Secondary Index
Approach 2: Composite key
Opponent StatusDate GameId Host
Alice DONE_2014-10-02 d9bl3 David
Carol IN_PROGRESS_2014-10-08 o2pnb Bob
Bob IN_PROGRESS_2014-10-03 ef9ca David
Bob PENDING_2014-09-30 72f49 Alice
Bob PENDING_2014-10-03 b932s Carol
59. Opponent StatusDate GameId Host
Alice DONE_2014-10-02 d9bl3 David
Carol IN_PROGRESS_2014-10-08 o2pnb Bob
Bob IN_PROGRESS_2014-10-03 ef9ca David
Bob PENDING_2014-09-30 72f49 Alice
Bob PENDING_2014-10-03 b932s Carol
Secondary Index
Approach 2: Composite key
Bob
SELECT * FROM Game
WHERE Opponent='Bob'
AND StatusDate BEGINS_WITH 'PENDING'
61. Sparse indexes
Id
(Part.)
User Game Score Date Award
1 Bob G1 1300 2012-12-23
2 Bob G1 1450 2012-12-23
3 Jay G1 1600 2012-12-24
4 Mary G1 2000 2012-10-24 Champ
5 Ryan G2 123 2012-03-10
6 Jones G2 345 2012-03-20
Game-scores-table
Award
(Part.)
Id User Score
Champ 4 Mary 2000
Award-GSI
Scan sparse partition GSIs
62. • Concatenate attributes to form useful
secondary index keys
• Take advantage of sparse indexes
Replace filter with indexes
You want to optimize a query as
much as possible
Status + Date
70. • Trade off read cost for write scalability
• Consider throughput per partition key and per
partition
Shard write-heavy partition keys
Your write workload is not
horizontally scalable
71. Correctness in voting
UserId Candidate Date
Alice A 2013-10-02
Bob B 2013-10-02
Eve B 2013-10-02
Chuck A 2013-10-02
RawVotes Table
Segment Votes
A_1 23
B_2 12
B_1 14
A_2 25
AggregateVotes Table
Voter
1. Record vote and de-dupe; retry 2. Increment candidate counter
72. Correctness in aggregation?
UserId Candidate Date
Alice A 2013-10-02
Bob B 2013-10-02
Eve B 2013-10-02
Chuck A 2013-10-02
RawVotes Table
Segment Votes
A_1 23
B_2 12
B_1 14
A_2 25
AggregateVotes Table
Voter
74. • Stream of updates to
a table
• Asynchronous
• Exactly once
• Strictly ordered
– Per item
• Highly durable
• Scale with table
• 24-hour lifetime
• Sub-second latency
DynamoDB Streams
75. View Type Destination
Old image—before update Name = John, Destination = Mars
New image—after update Name = John, Destination = Pluto
Old and new images Name = John, Destination = Mars
Name = John, Destination = Pluto
Keys only Name = John
View types
UpdateItem (Name = John, Destination = Pluto)
77. DynamoDB Streams
Open Source Cross-
Region Replication Library
Asia Pacific (Sydney) EU (Ireland) Replica
US East (N. Virginia)
Cross-region replication
84. Analytics with
DynamoDB Streams
• Collect and de-dupe data in DynamoDB
• Aggregate data in-memory and flush
periodically
Performing real-time aggregation
and analytics
consistent, single-digit millisecond latency at any scale
Fast, Consistent Performance [automatic partitioning, SSD technology]Highly Scalable [store as much data, limits are there for safety]
Fully Managed [choose key schema, tablename, provisioned capacity]
Event Driven Programming [Streams, Lambda/KCL]
Fine-grained Access Control [item-level, IAM credentials]
Flexible [doc, kv]
Online Indexing
Think of this as a parallel table asynchronously populated by DynamoDB
Eventually consistent
1 Table update = 0, 1 or 2 GSI updates
Think of this as a parallel table asynchronously populated by DynamoDB
Eventually consistent
1 Table update = 0, 1 or 2 GSI updates
There is a limit in place to avoid run-away apps. But you can request a limit increase.
http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Limits.html
For every distinct hash key value, the total sizes of all table and index items cannot exceed 10 GB
This request would have caused the ReadCapacityUnits limit to be exceeded for the account in us-west-2. Current ReadCapacityUnits reserved by the account: 237. Limit: 2000. Requested: 5000. Refer to the Amazon DynamoDB Developer Guide for current limits and how to request higher limits. (Service: AmazonDynamoDBv2; Status Code: 400; Error Code: LimitExceededException; Request ID: 0U3G4FLA19BQMELKS4G7RSTH83VV4KQNSO5AEMVJF66Q9ASUAAJG)
Picture from: http://www.amazon.com/Black-Aluminum-Control-Amplifier-Wheel/dp/B005HU1ZHA
Scan and Query
Cumulative size of processed items – ceiling (Ʃ(item sizes)/4KB)
Batch GetItem
ceiling [(Ʃ(item1 size)/4KB) + …ceiling (Ʃ(itemN size)/4KB)]
Consumed throughput is measured per operation
Provisioned throughput is divided between all partitions
Uneven access across key space
Per partition throughput
Provisioned
300 seconds of unused CU
RCU
1,666.67
500,001
WCU
166.67
50,000
This is used when a partition runs out of provisioned throughput due to bursts
Best effort delivery of burst capacity
Insufficient provisioning of RCU or WCU
If sustained throughput goes beyond provisioned throughput per partition
Key/values access patters (Map, Dictionary…)
http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Expressions.SpecifyingConditions.html
ProjectionExpression: Choose what attributes are returned
FilterExpression: Remove items from the response
ConditionalExpression: Do the op if the condition matches
UpdateExpression: list append, add/substract something
attribute_not_exists (#pr.FiveStar)
Tokens that begin with the : character are expression attribute values, which are placeholders for the actual value at runtime.
"ConditionExpression": "ForumName <> :f and Subject <> :s", "ExpressionAttributeValues": { ":f": {"S": "Amazon DynamoDB"}, ":s": {"S": "How do I update multiple items?"}
Touch on elasticity
Warn: You still consume IO even if the item doesn’t exist
Often some items in your table are accessed more frequently than others. For example, this graph illustrates how many requests per second were made for each item in your table. For collections like a product catalog, some items are substantially more popular than others. The same probably goes for tweets sent from a celebrity, and that sort of thing.
Displaying those “hot items” on everyone’s twitter feed is problematic since they cause an uneven request distribution.
(ask audience) Can anyone think of some things that we can do to “cool off” those hot items?
One thing we can do is cache those reads in the application.
Since a tweet doesn’t change once you post it, you can cache it in memory or in something like Amazon ElastiCache.
This is a technique used in high throughput applications with a traditional database as well.
50 messages to read from
Large items not necessarily expensive on their own, but the cost adds up
Query comes from same partition
Put the metadata into a GSI. 128 bytes versus 256KB
Last section was 5:25
This is your base table
filter will drop items, but you still pay for reads