NoSQL and AWS Dynamodb

2,701 views

Published on

Slides presenting a little explanation about NoSQL and AWS DynamoDB

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,701
On SlideShare
0
From Embeds
0
Number of Embeds
1,144
Actions
Shares
0
Downloads
29
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

NoSQL and AWS Dynamodb

  1. 1. AWS DynamoDB @nbluis http://about.me/nbluis
  2. 2. What ? • Database • NoSQL • AWS • SaaS
  3. 3. What ? •Database • NoSQL • AWS (IaaS, Paas)
  4. 4. What is a database ? Dammit! This is not for you!
  5. 5. What ? • Database •NoSQL • AWS (IaaS, Paas)
  6. 6. What do you mean?
  7. 7. 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
  8. 8. ACID ?
  9. 9. ACID
  10. 10. The cap theorem It’s impossible to simultaneously provide Availability Consistency Partition tolerance
  11. 11. Without partition tolerance guarantee We can be available (the data) and consistent RDBMS: Oracle, Postgres, MySQL, SQLServer, etc.
  12. 12. Without availability guarantee We can be highly scalable Big Table, Hypertable, HBase, MongoDB, Berkley DB, Memcache, Redis
  13. 13. Without consistency guarantee We can be highly replicable DynamoDB, Voldemort, Cassandra, SimpleDB, CouchDB, Riak
  14. 14. NoREL • ACID & JOINS are considered relational (unsupported) • Key-Value model • Column-oriented model • Document-oriented model
  15. 15. What ? • Database • NoSQL •AWS (IaaS, PaaS)
  16. 16. AWS
  17. 17. AWS • IaaS (Infrastructure as a Service) • PaaS (Platform as a Service) • Full managed DynamoDB service • Pay-as-you-go
  18. 18. DynamoDB • Fast • Full managed • Coast effective • Pay by throughput (reserved)
  19. 19. 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)
  20. 20. 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)
  21. 21. 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
  22. 22. 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
  23. 23. Thanks! @nbluis http://about.me/nbluis

×