Amazon DynamoDB is a fully managed NoSQL database service provided by AWS that provides fast and predictable performance with seamless scalability. It offers a flexible data model and reliable access patterns. With DynamoDB, users do not need to provision, operate, or scale their own database clusters and can instead pay only for the storage and throughput capacity they need.
3. Amazon DynamoDB is the result of everything we’ve learned from
building large-scale, non-relational databases for Amazon.com and
building highly scalable and reliable cloud computing services at AWS.”
11. Access and Query Model
• Two primary key options
•
•
Hash key: Key lookups: “Give me the status for user abc”
Composite key (Hash with Range): “Give me all the status updates for user ‘abc’
that occurred within the past 24 hours”
• Support for multiple data types
– String, number, binary… or sets of strings, numbers, or binaries
• Supports both strong and eventual consistency
– Choose your consistency level when you make the API call
– Different parts of your app can make different choices
• Local Secondary Indexes
14. This used to be the only way…
You Choose:
• Memory
• CPU
• Hard drive specs
• Software
• …
To get the database
performance you want:
• Throughput rate
• Latency
• …
15. This used to be the only way…
You Choose:
• Memory
• CPU
• Hard drive specs
• Software
• …
To get the database
performance you want:
• Throughput rate
• Latency
• …
21. Capacity Forecasting is Hard
When you run your own database, you need to:
• Try to forecast the scale you need
• Invest time and money learning how to scale your
database
• React quickly if you get it wrong
22. Timid Forecasting:
Plan for a lot more capacity than you probably need
Benefits:
• Safety – you know you’re ready
Risks:
• Buy too much capacity
• Lose development resources to
scale testing/planning
• Do more work than necessary
23. Aggressive Forecasting:
Cut it close! Plan for less capacity. Hope you don’t need
more…
Benefits:
• Lower costs if all goes well
Risks:
• Last-minute scaling emergencies
• How does your database behave at an
unexpected scale?
64. Key-Value Store Requirements
•
•
•
•
•
<10ms random key lookup with 100bytes values
5-10B items stored
Scale up and down without performance hit
~100% uptime, this is money for us
Consistent and sustained read/write throughput
65. Why DynamoDB instead of…
• Hbase: hbck like rain, really hard to manage
• Cassandra: still immature when we needed it
• Redis: limited by available memory, no
clustering
• Riak: great product, not fast enough for us
• MongoDB: not consistent write throughput
66. But the real reason…
They all require people to manage them!
And they all are hard to run in the cloud!
67. DynamoDB by Our Numbers
•
•
•
•
•
4 regions in use with live traffic replication
120B+ key fetches worldwide per day
1.5TB of data stored per region
30B+ items stored in reach region
<3ms uniform query latency, <10ms 99.95%
72. Tips for Optimum Performance
• Evenly distribute keys in
hash range
• All values should be about
the same size
• Cache reads for a few
seconds
• Buffer writes, when
necessary
• Exponential back-off
retries
73. What do you mean you don’t care about the money?