O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

NoSQL and AWS Dynamodb

3.291 visualizações

Publicada em

Slides presenting a little explanation about NoSQL and AWS DynamoDB

Publicada em: Tecnologia
  • Entre para ver os comentários

  • Seja a primeira pessoa a gostar disto

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

×