Database capacity planning is critical to running your business, but it’s also hard. In this session we’ll compare how scaling is usually performed for relational databases and NoSQL databases. We’ll look behind the scenes at how DynamoDB shards your data across multiple partitions and servers. Finally, we’ll talk about some of the recent enhancements to DynamoDB that make scaling even simpler, particularly a new feature called adaptive throughput that eliminates much of the throttling issues that you may have experienced.

1. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
AWS re:INVENT
DynamoDB Adaptive Capacity
R i c k H o u l i h a n
S e n i o r P r a c t i c e M a n a g e r — N o S Q L , A W S
N o v e m b e r 3 0 , 2 0 1 7
D A T 3 2 7

2. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Agenda
• Traditional approaches to database scaling
• How NoSQL databases scale compared to RDBMS
• Evolution of Amazon DynamoDB and adaptive
capacity

3. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Capacity Planning Is Important (and Hard)

4. Scaling Relational DBs

5. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Sharded Relational DBs?
A B C D
?

6. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
NoSQL Databases
• Denormalize and
shard to provide
horizontal scale
• Near unbounded
throughput and
storage
Collection 1
1 TB
Shard A
500 GB
Shard B
500 GB

7. The Iron Triangle of Data—All About CAP
C
A
PConsistency:
all clients always have
the same view of data
Partition tolerance:
the system works well
despite physical network
partitions
Availability:
all clients can always
read and write
CA
MSSQL
Oracle
DB2
MySQL
Aster Data
Greenplum
Postgres
CP
Big Table
Hypertable
Hbase
MongoDB
Terastore
Couchbase
Scalaris
DynamoDB
BerkeleyDB
Memcache
Redis
Pick Two
AP
Voldemort
Tokyo Cabinet
KAI
DynamoDB
Cassandra
SimpleDB
CouchDB
Riak
MongoDB
Data Models:
Relational
Wide Column
Document
Key/Value
© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

8. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Product Database
ID
Type
Price
Description
Products
ID
Title
Category
Fiction
Producer
Director
…
Videos
ID
Artist
Title
Genre
…
Albums
ID
Author
Title
Fiction
Category
Date
…
Books
{
Product ID,
Type,
Price,
Description,
Author,
Title,
Fiction,
Category,
Date,
…
}
ID
AlbumID
Title
Duration
…
Tracks
ActorID
VideoID
ActorVideo
ID
Name
Age
Gender
Bio
…
Actors
{
Product ID,
Type,
Price,
Description,
Artist,
Title,
Genre,
Tracks: [ {
Title1,
Duration1
},{
Title2,
Duration2,
} ]
…
}
{
Product ID,
Type,
Price,
Description,
Title,
Category,
Fiction,
Producer,
Director,
Actors: [ {
ActorID,
Name,
Age,
Gender,
ShortBio
}, … ]
}
Normalization Aggregation
SQL vs. NoSQL Design Pattern

9. Scaling NoSQL DBs
© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

10. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Why NoSQL?
Optimized for storage Optimized for compute
Normalized/relational Denormalized/hierarchical
Ad hoc queries Instantiated views
Scale vertically Scale horizontally
Good for OLAP Built for OLTP at scale
SQL NoSQL

11. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Amazon DynamoDB
Document or key-value Scales to any workloadFully managed NoSQL
Access control Event-driven programmingFast and consistent

12. 00 55 A954 FFAA00 FF
Partition Keys in NoSQL
Id = 1
Name = Jim
Hash (1) = 7B
Id = 2
Name = Andy
Dept = Eng
Hash (2) = 48
Id = 3
Name = Kim
Dept = Ops
Hash (3) = CD
Key Space
Partition Key uniquely identifies an item
Partition Key is used for building an unordered hash index
Allows table to be partitioned for scale
© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

13. 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
© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

14. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Server 1
T1.p1
Table1 Table2 Table3
Server N
T1.p2
Behind the scenes…
1K WCU or 3K RCU
Up to 10 GB

15. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
DynamoDB Scaling

16. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Exact—forget whole server increments
Quick—additional capacity in minutes
Elastic—meet your needs, up and down
• Maximize availability
• Minimize cost
• No downtime

17. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Hundreds of thousands of customers
Millions of requests per second
Hundreds of billions of items
Petabytes of storage
Results

18. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Adaptive Capacity
Get it right, nobody notices.
Get it wrong, everybody will.

19. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
T1
Server 1
A
Dynamic Scaling—Throughput and Storage
500 WCU, 150K BURST, 1K PEAK
1500 RCU, 450K BURST, 3K PEAK
Up to 5 minutes of sustained 1K WCU or 3K RCU burst
500 WCU
1500 RCU

20. Server 1
T1
Server 2
A B
Dynamic Scaling—Throughput and Storage
500 WCU, 150K BURST, 2K PEAK
1500 RCU, 450K BURST, 6K PEAK
250 WCU
750 RCU
250 WCU
750 RCU
Up to 100 seconds of sustained 2K WCU or 6K RCU burst
© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

21. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Server 1
T1
Server 2
A B
Dynamic Scaling—Throughput and Storage

22. Server 1
T1
Server 2 Server 3
A B C
Dynamic Scaling—Throughput and Storage
500 WCU, 150K BURST, 3K PEAK
1500 RCU, 450K BURST, 9K PEAK
250 WCU
500 RCU
125 WCU
375 RCU
125 WCU
375 RCU
Up to 1 minute of sustained 3K WCU or 9K RCU burst
© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

23. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Server 1
T1
Server 2 Server 3
A B C
Dynamic Scaling—Throughput and Storage

24. Server 1
T1
Server 4 Server 2 Server 3
A D B C
Dynamic Scaling—Throughput and Storage
500 WCU, 150K BURST, 4K PEAK
1500 RCU, 450K BURST, 12K PEAK
125 WCU
375 RCU
125 WCU
375 RCU
125 WCU
375 RCU
125 WCU
375 RCU
Up to 43 seconds of sustained 4K WCU or 12K RCU burst
© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

25. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Scenario: Census Application
Statistics Canada (Canada's national statistical agency)
hires you to build an online census application
You choose DynamoDB with the following key schema:
Partition Key: province
Sort Key: id

26. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
What you didn’t realize…

27. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Partition 1
T1
Partition 2 Partition 3 Partition 4
DynamoDB Throughput Allocation
100
25 25 25 25
Ontario, Quebec,
Newfoundland, Prince
Edward Island
British Columbia,
Alberta, Sakatchewan
Manitoba, Nova Scotia,
Northwest Territories
New Brunswick,
Nunavut, Yukon

28. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
So What Happens?
Partition soft limits exceeded

29. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Adaptive Throughput Kicks In
Helped more than 2,800 Amazon tables and indexes on
Prime Day!

30. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

31. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Auto Scaling
With Auto ScalingWithout Auto Scaling
Throughput automatically adapts to your actual traffic

32. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

33. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Time-to-Live (TTL)
Features
• Automatic: deletes items from a table based on expiration timestamp
• Customizable: user-defined TTL attribute in epoch time format
• Audit log: TTL activity recorded in Amazon DynamoDB Streams
Benefits
• Reduce costs: delete items when no longer needed
• Performance: optimize app performance by controlling table size growth
• Extensible: trigger custom workflows (e.g. auto-archive to Glacier) with
DynamoDB Streams, AWS Lambda, Amazon Kinesis, etc.

34. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
TTL Results
Purged 85 terabytes of stale data and reduced their costs by over
$200K per year, while also simplifying their application logic
Amazon CloudWatch
• “Reduced our overall provisioned throughput by 75 percent,”
• “And with that reduction, data-retrieval latencies were also
reduced by up to 10 percent.”
• “Expect to save millions of dollars annually.”

35. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Managing Databases
Provisioning
Capacity planning
Monitoring
OS patching
Hardware upgrades
Database upgrades
Security patches
Scaling
Monitoring
Performance tuning
Replication across datacenters
Re-replicate on server failureProvision new regions
Servers Databases
With zero downtime???

36. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Fully Managed, Adaptive, Database Service
Provisioning
Capacity planning
Monitoring
OS patching
Hardware upgrades
Database upgrades
Security patches
Scaling
Monitoring
Performance tuning
Replication across datacenters
Re-replicate on server failureProvision new regions
Servers Databases
All with zero downtime!!!

37. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Thank you!