This document provides an overview of AWS DynamoDB, a fully managed NoSQL database service by AWS. It discusses that DynamoDB is a key-value and document database that offers fast performance and scalability. While this comes with some tradeoffs, as DynamoDB follows the CAP theorem and sacrifices consistency in favor of availability and partition tolerance. The document also covers DynamoDB's data model, pricing, features, and limitations to provide essential information on what it is and how it works at a high level.

1. AWS DynamoDB
@nbluis
http://about.me/nbluis

2. What ?
• Database
• NoSQL
• AWS
• SaaS

3. What ?
•Database
• NoSQL
• AWS (IaaS, Paas)

4. What is a database ?
Dammit!
This is not for you!

7. What ?
• Database
•NoSQL
• AWS (IaaS, Paas)

8. What do you mean?

10. NoSQL vs NewSQL
• NoSQL is a really bad label
• It’s not about SQL
• It’s about better performance or
scalability
• Sometimes we can live without ACID

11. ACID ?

12. ACID

13. The cap theorem
It’s impossible to simultaneously provide
Availability
Consistency
Partition tolerance

14. Without partition
tolerance guarantee
We can be available (the data)
and consistent
RDBMS: Oracle, Postgres, MySQL, SQLServer, etc.

15. Without availability
guarantee
We can be highly scalable
Big Table, Hypertable, HBase, MongoDB,
Berkley DB, Memcache, Redis

16. Without consistency
guarantee
We can be highly replicable
DynamoDB, Voldemort, Cassandra, SimpleDB,
CouchDB, Riak

17. NoREL
• ACID & JOINS are considered
relational (unsupported)
• Key-Value model
• Column-oriented model
• Document-oriented model

18. What ?
• Database
• NoSQL
•AWS (IaaS, PaaS)

19. AWS

20. AWS
• IaaS (Infrastructure as a Service)
• PaaS (Platform as a Service)
• Full managed DynamoDB service
• Pay-as-you-go

21. DynamoDB
• Fast
• Full managed
• Coast effective
• Pay by throughput (reserved)

22. The good parts
• Table based (each table is
independent)
• Schema free (except the Key)
• Really fast to find using Primary and
Range Keys
• Support for complex queries (Scan)

23. The “must know” parts
• Eventual consistency by default, with
high costs to ensure consistency.
• Must use SDK/API to access
• 64K is the max “row” size
• Complex queries are made using
Sequential/Full Table Scan (high cost)

24. The bad parts
• Very limited data types (text, number,
binary)
• No way to join tables
• More than 64k of data per item
requires “workarounds”
• It’s not possible to copy a table to
another one

25. Final considerations
Pros:
• Really fast using IDs
• Really cost effective
• Full managed is a
good idea
• A good option for
key-value situations
Cons
• Very limited with
types and joins
• Complex queries are
costly

26. Thanks!
@nbluis
http://about.me/nbluis