NoSQL and AWS Dynamodb
0 likes3,956 views
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.
NoSQL and AWS Dynamodb
- 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