Persistência nas Nuvens com NoSQL

2.456 visualizações

Publicada em

Computação em Nuvem
Persistência de Dados
Bancos de Dados Relacionais
Movimento NoSQL
Modelo de dados do Bigtable da Google
Arquitetura do Dynamo da Amazon
Detalhes técnicos do Apache Cassandra

Publicada em: Tecnologia
  • Seja o primeiro a comentar

Persistência nas Nuvens com NoSQL

  1. 1. Persistência nas Nuvens com NoSQL Rodrigo Hjort [email_address]
  2. 2. Quem aqui usa banco de dados?
  3. 3. Por que precisamos de SQL?
  4. 4. Onde usamos SQL (i.e. ACID)?
  5. 5. <ul>MAS... </ul>
  6. 6. Universo digital em expansão Fonte: IDC White Paper, &quot;The Diverse and Exploding Digital Universe&quot;, 2008.
  7. 7. Aplicações web modernas
  8. 8. <ul>Escalabilidade vertical é complicada e/ou cara! </ul>
  9. 9. Os modelos transacionais <ul><li>ACID pessimista, forçando consistência ao final de cada operação
  10. 10. BASE otimista, aceitando que a consistência esteja em um “estado de fluxo” </li></ul>http://queue.acm.org/detail.cfm?id=1394128 Possibilita a escalabilidade horizontal...
  11. 11. NoSQL = Not Only SQL http://nosql-database.org/ distribuídos não relacionais horizontalmente escaláveis esquemas flexíveis replicáveis APIs simples
  12. 12. NoSQL nas Nuvens escalabilidade flexibilidade performance disponibilidade
  13. 13. Zoologia dos bancos NoSQL Wide Column Store / Column Families Key-Value Store Document Store Azure Storage Services
  14. 14. <ul>MAS... </ul>
  15. 15. <ul>Você precisa escolher 2! </ul>Teorema de Brewer: CAP <ul><li>Consistência : visão única para os clientes
  16. 16. Disponibilidade : toda operação tem uma resposta
  17. 17. Partição : sistema continua operante mesmo enfrentando partições na rede </li></ul>Consistência Consistency Disponibilidade Availability Partição Partition Tolerance
  18. 18. Breve explicação do CAP um dia ensolarado... partições de rede!
  19. 19. I. Consistência e Disponibilidade <ul><li>Limitações na escalabilidade (leitura e escrita) </li></ul>C A
  20. 20. II. Consistência e Partição <ul><li>Completamente inacessível se qualquer um dos nós estiver fora! </li></ul>C P
  21. 21. III. Disponibilidade e Partição <ul><li>Nem sempre lê a informação mais recente: futuramente consistente </li></ul>A P
  22. 22. “ A high performance, scalable, distributed storage and processing system for structured and unstructured data.”
  23. 23. Cassandra: um breve histórico Bigtable Dynamo
  24. 24. Um novo modelo de dados Agrupamento de famílias de colunas (~banco de dados) Agrupamento de colunas (~tabela) com ordenação fixada Chave que representa uma linha de colunas (~chave primária) Representação de um valor, com: <ul><li>Nome (Name)
  25. 25. Valor (Value)
  26. 26. Timestamp </li></ul>Keyspace Column Family (Row) Key Column
  27. 27. As famílias de colunas
  28. 28. Exemplo: modelagem do Twitter Users Following Followers @paul segue @brigitte desde 22/08/2010 john fullname: John Doe password: swordfish joindate: 20091115 paul fullname: Paul Lane password: thepass joindate: 20091129 john paul: 20091204 brigitte: 20100815 paul john: 20091205 debora: 20100729 brigitte: 20100822 john tom: 20091128 paul: 20091205 brigitte john: 20100815 paul: 20100822
  29. 29. Exemplo: modelagem do Twitter Statuses (Tweets) Timeline Userline Tweets do @john Tweets dos usuários que o @paul segue data/hora tweet 12345 user: john body: Nuvem privada do @serpro! retweets: 123 12346 user: brigitte john 20100116083155: 12346 paul 20100116083002: 12345 20100116083155: 12346 john 20100116083002: 12345 20100118235914: 23457 brigitte 20100116083155: 12346 tweet body: Acabei de #acordar. tags acordar: 1
  30. 30. “It took two weeks to perform ALTER TABLE on the statuses [tweets] table.” – Twitter
  31. 31. Particionamento e replicação Fixed Circular Space (Ring) Virtual Nodes Consistent Hashing (MD5) <ul>N=3 </ul><ul>h(key2) </ul><ul>0 </ul><ul>1 </ul><ul>1/2 </ul><ul>F </ul><ul>E </ul><ul>D </ul><ul>C </ul><ul>B </ul><ul>A </ul><ul>h(key1) </ul>
  32. 32. Ajuste de parâmetros (N, R, W) <ul><li>Consistência versus Escalabilidade
  33. 33. Ajuste por requisição (R, W) </li><ul><li>Zero
  34. 34. One
  35. 35. Quorum: N / 2 + 1
  36. 36. All </li></ul><li>N: réplicas
  37. 37. R + W > N
  38. 38. Read repair </li></ul>ack cliente réplica réplica réplica coordenador
  39. 39. Filiação cluster / detecção falha Gossip-Based Protocol
  40. 40. Relacional versus NoSQL Dados do benchmark <ul><li>Base com 50 GB de dados </li></ul>MySQL <ul><li>leitura: ~350 ms
  41. 41. escrita: ~300 ms </li></ul>Cassandra <ul><li>leitura: ~15 ms
  42. 42. escrita: ~0,12 ms </li></ul>Leitura 23x mais rápida! Escrita 2500x mais rápida!
  43. 43. Escrita é mais rápida que leitura?!
  44. 44. “ NoSQL adoption is inevitable because, just as in every other walk of life, there are different tools for different jobs” – Stephen O'Graddy (RedMonk) Rodrigo Hjort [email_address] http://agajorte.blogspot.com

×