Modelos NoSQL e a Persistência Poliglota

1.990 visualizações

Publicada em

Palestra sobre NoSQL apresentada no 10a ERBD no Instituto Federal Catarinense de São Francisco

Publicada em: Software
1 comentário
18 gostaram
Estatísticas
Notas
Sem downloads
Visualizações
Visualizações totais
1.990
No SlideShare
0
A partir de incorporações
0
Número de incorporações
39
Ações
Compartilhamentos
0
Downloads
0
Comentários
1
Gostaram
18
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Modelos NoSQL e a Persistência Poliglota

  1. 1. Modelos NoSQL e a Persistência Poliglota (com pitadas de Big Data) ERDB 2014 Programa de Pós-Graduação em Computação Aplicada Prof. Orientador: Fabiano Baldo, PhD Mestrando: Glaucio Scheibel UNIVERSIDADE DO ESTADO DE SANTA CATARINA-UDESC CENTRO DE CIÊNCIAS TECNOLÓGICAS-CCT v.2
  2. 2. Agenda • Ser Poliglota • Big Data • O Teorema CAP • ACID x BASE • NoSQL • Além do Relacional • Map-Reduce • JSON e BSON • Modelos de dados NoSQL – Chave-Valor – Documento – Família de colunas – Grafo
  3. 3. Ser Poliglota
  4. 4. Poliglotismo • s.m. Característica da pessoa que é poliglota. Habilidade ou aptidão para falar várias línguas (idiomas). (Etm. poliglota + ismo)
  5. 5. Programação Poliglota • Termo criado por Neal Ford em 2006. • Hoje quando desenvolvemos um projeto, já não usamos mais apenas uma linguagem. – SQL na camada de persistência – Java, C#, Python ou similar na camada de negócio – HTML e Javascript na camada de apresentação • “Applications of the future will take advantage of the polyglot nature of the language world” – Ford, 2006
  6. 6. Persistência Poliglota • Similar a Programação Poliglota onde temos um mix de linguagens, poderíamos também ter um mix de modelos de dados. • Diferentes bancos de dados são desenhados para resolver diferentes problemas. (Sadalage e Fowler 2013)
  7. 7. RDBMS para todo o Armazenamento Fonte: Sadalage e Fowler
  8. 8. Persistência Poliglota Fonte: Sadalage e Fowler
  9. 9. Persistência Poliglota SOA Fonte: Sadalage e Fowler
  10. 10. Big Data
  11. 11. NoSQL e BigData • NoSQL ≠ BigData • BigData: – Quantidade de dados que ultrapassa alguns Terabytes • Tamanho que necessita mais de um storage. • Tamanho onde técnicas tradicionais de RDBMS começam a mostrar sinais de stress. – Crescimento em 3 V’s • Velocidade • Variedade • Volume
  12. 12. BigData e os 3 V’s
  13. 13. Estatísticas Tweeter (Mar/14) • Usuários: 1 Bilhão • Tweets enviados: 300 Bilhões • Tweets/dia: 500 Milhões • Usuários ativos/mês: 241 Milhões • Média seguidores: 208/usuário • Recorde tweets/seg.: 143.199 em 03/08/2013 Fonte: Digital Marketing Ramblings
  14. 14. Estatísticas Facebook (Mar/14) • Usuários: 1,26 Bilhões (140 Milhões fakes) • Usuários ativos/dia: 757 Milhões • Likes/dia: 4,5 Bilhões • Fotos/dia: 350 Milhões • Páginas: 50 Milhões • Aplicações: 10 Milhões • Total de Likes: 1,13 Trilhões • Total de dados: 300 Petabytes Fonte: Digital Marketing Ramblings
  15. 15. Estatísticas Youtube (Fev/14) • Usuários: 1 Bilhão • Visualizações por dia: 4 Bilhões • Horas por mês: 6 Bilhões • Qtde de upload/min: 100 Horas de vídeo Fonte: Digital Marketing Ramblings
  16. 16. Big Data • De acordo com pesquisa da GigaOM: – 90% dos dados armazenados no mundo foram gerados nos 2 últimos anos. – 80% destes dados não são estruturados. • Definição em um post de Richard Dale1: – “Big Data são dados que crescem em volume, variedade e velocidade acima da Lei de Moore.” 1http://venturecyclist.blogspot.com.br/2012/08/a-better-definition-of-big-data.html
  17. 17. “Hoje, em um único dia, estamos criando mais dados do que a humanidade toda criou desde o seu início até o ano 2000.” Andreas Weigend / IAB fórum 2013
  18. 18. Fonte: IBM
  19. 19. O que é Big Data? • É o termo aplicado a dados que não podem ser processados ou analisados usando processos e ferramentas tradicionais (Zikopoulos et al., 2012) • “Big data” is high-volume, -velocity and -variety information assets that demand cost-effective, innovative forms of information processing for enhanced insight and decision making. (Gartner, 2012).
  20. 20. Artigos BigTable e Dynamo • Google BigTable (2006) – Modelo família de colunas – “Internet Scale” • Web Search: 1.2 milhões de requisições por segundo. • Google analytics: 200 TB (base) + 20 TB (sumário) • Google Earth: 70 TB • Amazon Dynamo (2007) – Modelo chave-valor – Amazon’s Always-on Experience • “Always writable” • SLA: resposta dentro de 300ms em 99,9% das requisições
  21. 21. O Teorema CAP
  22. 22. Teorema CAP • N1 e N2 são dois nós na rede • Duas bases dados com valor V0 • Programas A e B Fonte: Browne, 2010
  23. 23. Execução sem Falha de Rede Fonte: Browne, 2010
  24. 24. Execução com Falha de Rede Fonte: Browne, 2010
  25. 25. Sincronização Fonte: Browne, 2010
  26. 26. Teorema CAP [Brewer] • Consistency – Consistência. – Todos os clientes veem o mesmo dado, mesmo com a presença de updates. • Availability – Disponibilidade. – Todos os clientes acham uma réplica do dado mesmo na presença de falhas. • Partition-tolerance – tolerante a particionamento – As propriedades do sistema são mantidas mesmo quando este é particionado.
  27. 27. Teorema CAP [Brewer] • Pode-se ter no máximo duas destas propriedades para qualquer sistema de dados compartilhado. – Consistência – Disponibilidade – Tolerância a partições de rede.
  28. 28. O Teorema CAP foi Comprovado • “É impossível no modelo assíncrono de rede implementar uma leitura / gravação de objetos de dados que garanta as propriedades de disponibilidade e consistência atômica em todas as execuções justas (incluindo aqueles em que as mensagens são perdidos).” [Gilbert e Lynch, 2002]
  29. 29. ACID x BASE
  30. 30. ACID • Atomicity – Requer que toda transação seja “Ou tudo ou nada”. • Consistency – Uma transação leva a base de dados de um estado consistente a outro. • Isolation – Uma transação não interfere em outra, como estivessem sendo executadas uma após a outra. • Durability – Uma vez “comitada”, as modificações da transação são mantidas. Header e Reuter, 1983
  31. 31. BASE (Consistência Eventual) • Basically Available – Haverá uma resposta a qualquer requisição. – O armazenamento parece funcionar a maior parte do tempo. • Soft state – Armazenamentos não tem que ter uma escrita consistente, nem as réplicas têm de ser coerentes entre si o tempo todo. • Eventual consistency – O sistema, eventualmente, ficará consistente após parar de receber as entradas de dados.
  32. 32. ACID x BASE ACID • Forte consistência • Isolamento • Foco no “commit” • Transações aninhadas • Disponibilidade? • Conservador (pessimista) • Evolução difícil (schema) BASE • Consistência fraca • Disponibilidade é prioridade • Respostas aproximadas são OK • Agressivo (otimista) • Mais simples! • Mais rápido • Evolução fácil Brewer, 2000
  33. 33. NoSQL
  34. 34. NoSQL • Termo sugerido por Eric Evans para um encontro em 2009 em San Francisco organizado por Johan Oskarson (last.fm). – Dava uma boa hashtag no Twitter • NoSQl é um movimento, não uma tecnologia. • Não há órgão regulamentador. • Não há consenso com relação ao significado. – No SQL – Not Only SQL – NOSQL – no:sql
  35. 35. Definição NoSQL • É a geração de bancos de dados que possuem as seguintes características: ser não relacional, distribuído, open-source e horizontalmente escalável. – nosql-database.org
  36. 36. Seis Características NoSQL 1. Capacidade de escalar horizontalmente uma simples operação através de muitos servidores. 2. Capacidade de replicar e de distribuir os dados ao longo de muitos servidores (partições). 3. Ter um protocolo ou interface simples de comunicação (em contraste com SQL). 4. um modelo de concorrência mais fraca do que as transações ACID. 5. Utilização eficiente dos índices e memória RAM para o armazenamento de dados distribuídos. 6. Capacidade de adicionar novos atributos dinamicamente nos registros de dados. Fonte: Catell, 2011
  37. 37. Além do Relacional
  38. 38. Agregação • É uma coleção de dados relacionados que é tratado como uma unidade. • É o limite de uma operação ACID / BASE. • O modelo relacional é considerado aggregate- ignorant.
  39. 39. Agregação: Modelo Relacional
  40. 40. Agregação: Modelo Relacional
  41. 41. Agregação: Modelo Agregado
  42. 42. Agregação: Modelo Agregado
  43. 43. Além do Relacional • Da perspectiva de desenvolvimento de aplicações, bancos de dados relacionais são a resposta, independentemente da pergunta. [O’Grady, 2013]
  44. 44. Além do Relacional • Bancos de dados relacionais são consolidados e amplamente utilizados, mas... – Golden Hammer Anti-pattern • Confiança excessiva na ferramenta favorita. • Resolver diferentes problemas com uma mesma ferramenta. • “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.” - Abraham H. Maslow – “One size fits all”
  45. 45. A Garagem Relacional
  46. 46. Dificuldade na Evolução
  47. 47. Schemaless • Agilidade e flexibilidade no desenvolvimento e evolução do software. • Existe um “Schema Implícito” que é função da aplicação e não da camada de persistência. – set “cliente.1.nome” “ABC Transportes” – set “cliente.2.razao” “XYZ Comercio” // Ops! Fonte: Sadalage e Fowler, 2012
  48. 48. Agilidade em Software • Agilidade em software é a capacidade de se adaptar o software rapidamente às mudanças de requisitos de negócios. • Agilidade é fortemente associada tanto a robustez operacional quanto a produtividade do desenvolvedor. • A agilidade é mais do que criar rapidamente novas aplicações; significa ser capaz de responder às mudanças de regras de negócio, sem reescrever o código. Fonte: McCreary e Kelly, 2013
  49. 49. MapReduce
  50. 50. MapReduce • É construído sobre o conceito comprovado de dividir e conquistar: é muito mais rápido quebrar uma enorme tarefa em pequenos pedaços e processá-los em paralelo. (Schneider, 2012) • MapReduce é um modelo de programação desenhado para processar grandes volumes de dados em paralelo, dividindo o trabalho em um conjunto de tarefas independentes. (Wikipedia, 23/04/14)
  51. 51. Map Step • O nó mestre pega uma entrada, separa em sub-problemas menores, e os distribui para nós workers. Um worker pode fazê-lo novamente, que por sua vez, conduz a uma estrutura de árvore de múltiplos níveis. O worker processa esse problema menor, e passa a resposta de volta para o nó mestre. Fonte: http://mapreduce.org
  52. 52. Map Step Fonte: Sadalage e Fowler, 2012
  53. 53. Reduce Step • O nó mestre, em seguida, pega as respostas de todos os sub-problemas e os combina de forma a obter o resultado, que é a resposta para o problema original. Fonte: http://mapreduce.org
  54. 54. Reduce Step Fonte: Sadalage e Fowler, 2012
  55. 55. JSON e BSON
  56. 56. JSON • JSON (JavaScript Object Notation - Notação de Objetos JavaScript) é uma formatação leve de troca de dados. – Para seres humanos, é fácil de ler e escrever. – Para máquinas, é fácil de interpretar e gerar. • Constituído em duas estruturas: – Uma coleção de pares nome/valor. – Uma lista ordenada de valores. Fonte: http://www.json.org
  57. 57. Exemplo JSON {"widget": { "debug": "on", "window": { "title": "Sample Konfabulator Widget", "width": 500, "height": 500 }, "image": { "src": "Images/Sun.png", "hOffset": 250, "vOffset": 250, "alignment": "center" }, "text": { "data": "Click Here", "size": 36, "style": "bold", "name": "text1", "hOffset": 250, "vOffset": 100, "alignment": "center" } }}
  58. 58. BSON • Abreviação de Binary JSON, é a serialização binária de documentos JSON. • Vantagens sobre JSON: – Tipos além do String • byte, int32, int64, double, boolean, datetime, timestamp Fonte: http://bson.org
  59. 59. Exemplo BSON
  60. 60. Os Modelos NoSQL
  61. 61. Modelo Chave-Valor • Base simples baseada em Tabela Hash. – Uma tabela de duas colunas: Key, Value • Key: String, Value: Blob • Modelo mais simples.
  62. 62. Modelo Chave-Valor Bucket: coleção de chave-valor no Riak
  63. 63. Ranking Chave-Valor Fonte: db-engines.com
  64. 64. Prática • Usar banco chave-valor com Redis • http://redis.io
  65. 65. Modelo Documento • Baseados em documentos (xml, json, bson...) – Não confundir com documentos de texto, planilhas, etc • O documento é considerado um todo, evitando a divisão do dado. • Forte modelo agregado.
  66. 66. Modelo Documento JSON { "firstname": "Pramod", "citiesvisited": [ "Chicago", "London", "Pune", "Bangalore" ], "addresses": [ { "state": "AK", "city": "DILLINGHAM", "type": "R" }, { "state": "MH", "city": "PUNE", "type": "R" } ], "lastcity": "Chicago" } XML <person> <firstname>Pramod</firstname> <citiesvisited> <cityvisited>Chicago</cityvisited> <cityvisited>London</cityvisited> <cityvisited>Pune</cityvisited> <cityvisited>Bangalore</cityvisited> </citiesvisited> <addresses> <address> <state>AK</state> <city>DILLINGHAM</city> <type>R</type> </address> <address> <state>MH</state> <city>PUNE</city> <type>R</type> </address> </addresses> <lastcity>Chicago</lastcity> </person>
  67. 67. Ranking Documento Fonte: db-engines.com
  68. 68. Ranking Documento XML Fonte: db-engines.com
  69. 69. Prática • Usar um banco documento com MongoDB. • Linguagem JavaScript • http://www.mongodb.org
  70. 70. Modelo Família de Colunas • A unidade de informação é a coluna (chave-valor) e um “registro” é uma família de colunas. • Coluna: – Par chave-valor • Super coluna: – Array de colunas • Família de colunas: – Um container para colunas ordenadas por seus nomes. Família de colunas são referenciadas e classificadas por rowkeys. • Família de super colunas: – Um container para super colunas ordenados por seus nomes. Famílias como Coluna, Famílias de super coluna são referenciados e ordenados por rowkeys. Fonte: http://www.sinbadsoft.com/blog/cassandra-data-model-cheat-sheet
  71. 71. Modelo Família de Colunas Fonte: Sadalage e Fowler 2012
  72. 72. Coluna Fonte: http://www.sinbadsoft.com/blog/cassandra-data-model-cheat-sheet
  73. 73. Super Coluna Fonte: http://www.sinbadsoft.com/blog/cassandra-data-model-cheat-sheet
  74. 74. Família de Colunas Fonte: http://www.sinbadsoft.com/blog/cassandra-data-model-cheat-sheet
  75. 75. Família de Super Colunas Fonte: http://www.sinbadsoft.com/blog/cassandra-data-model-cheat-sheet
  76. 76. Ranking Família de Colunas Fonte: db-engines.com
  77. 77. Prática • Usar um banco família de colunas com o Apache Cassandra • Linguagem CQL • http://cassandra.apache.org
  78. 78. Modelo em Grafos • Dados organizados em nós e vértices. • Modelo onde o foco é o relacionamento.
  79. 79. Modelo em Grafos
  80. 80. Uma pequena rede social
  81. 81. Busca de Amigos Relacional • Amigos: – select distinct uf.* from t_user_friend uf where uf.user_1 = ? • Amigos dos Amigos: – select distinct uf2.* from t_user_friend uf1 inner join t_user_friend uf2 on uf1.user_1 = uf2.user_2 where uf1.user_1 = ? • Amigos dos Amigos dos Amigos: – select distinct uf3.* from t_user_friend uf1 inner join t_user_friend uf2 on uf1.user_1 = uf2.user_2 inner join t_user_friend uf3 on uf2.user_1 = uf3.user_2 where uf1.user_1 = ? Fonte: Partner 2013
  82. 82. Rede Social Grafo
  83. 83. Busca de Amigos Grafo • TraversalDescription traversalDescription = Traversal.description(). relationships(“IS_FRIEND_OF”, Direction.OUTGOING).evaluator(Evaluators.a tDepth(2)).uniqueness(Uniqueness.NODE_GLOB AL); • Iterable<Node> nodes = traversalDescription. traverse(nodeById). nodes();
  84. 84. Busca de Amigos • 1.000.000 usuários com 50 amigos • MySql: Fonte: Partner 2013
  85. 85. Busca de Amigos • 1.000.000 usuários com 50 amigos • Neo4j: Fonte: Partner 2013
  86. 86. Por que o tempo do Relacional? • Para encontrar todos os amigos de um usuário em profundidade 5, um motor de banco de dados relacional precisa gerar o produto cartesiano da tabela t_user_friend cinco vezes. Com 50.000 registros na tabela, o conjunto resultante terá 50.0005 linhas (102,4 × 1021), o que leva bastante tempo e poder computacional para calcular. Em seguida, descartar mais de 99% dos dados, para retornar apenas 1000 registros! Fonte: Partner 2013
  87. 87. Por que o tempo do Grafo? • Devido a estrutura de dados. • Se alguém lhe perguntar quantas pessoas estão sentados a 5 metros em torno de você, você vai se levantar e contá-los. Se o estádio está meio vazio, você vai contar com as pessoas ao seu redor tão rápido quanto você pode contar. Se o estádio está lotado, você ainda vai fazê-lo em um tempo semelhante. Fonte: Partner 2013
  88. 88. Ranking Grafos Fonte: db-engines.com
  89. 89. Prática • Usar um banco em grafo com o Neo4J • Linguagem Cypher • http://www.neo4j.org
  90. 90. Resumo: Big Data • É o termo aplicado a dados que não podem ser processados ou analisados usando processos e ferramentas tradicionais (Zikopoulos et al., 2012) • 3 V’s – Volume – Variedade – Velocidade
  91. 91. Resumo: Bancos NoSQL • Open-Source – Movimento • Roda em computadores “commodity”. – Baixo custo. • Criado para clusters. – Adição e remoção de nós sem impacto na operação. • Consistência eventual. – BASE invés de ACID • Não utiliza SQL • Schemaless – Flexibilidade – Produtividade • Versionamento no lugar de atualização de dados. – Timestamp • Sem transação de múltiplas chaves. • Suporte ao BigData.
  92. 92. Obrigado
  93. 93. Referências • BANKER, Kyle. MongoDB in action. Manning Publications Co., 2011. • BEYER, Mark A.; LANEY, Douglas. The Importance of ‘Big Data’: A Definition. Stamford, CT: Gartner, 2012. • BREWER, Eric A. Towards robust distributed systems. In: PODC. 2000. p. 7. • BROWNE, Julian. Brewer’s CAP Theorem-The kool aid Amazon and Ebay have been drinking. 2010. • CATTELL, Rick. Scalable SQL and NoSQL data stores. ACM SIGMOD Record, v. 39, n. 4, p. 12-27, 2011.
  94. 94. Referências • CHANG, Fay et al. Bigtable: A distributed storage system for structured data. ACM Transactions on Computer Systems (TOCS), v. 26, n. 2, p. 4, 2008. • COOPER, Brian F. et al. PNUTS: Yahoo!'s hosted data serving platform. Proceedings of the VLDB Endowment, v. 1, n. 2, p. 1277-1288, 2008. • DECANDIA, Giuseppe et al. Dynamo: amazon's highly available key-value store. In: SOSP. 2007. p. 205-220. • ELMASRI, Ramez; NAVATHE, Shamkant B.; DE OLIVEIRA MORAIS, Rinaldo. Sistemas de banco de dados. 2005.
  95. 95. Referências • FORD, Neal. Polyglot programming. 2006. • GILBERT, Seth; LYNCH, Nancy. Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services. ACM SIGACT News, v. 33, n. 2, p. 51-59, 2002. • HAERDER, Theo; REUTER, Andreas. Principles of transaction-oriented database recovery. ACM Computing Surveys (CSUR), v. 15, n. 4, p. 287-317, 1983. • LANEY, Douglas. 3-D Data Management: Controlling Data Volume, Velocity and Variety. META Group Research Note, February, v. 6, 2001. • MADDEN, Sam. From databases to big data. Internet Computing, IEEE, v. 16, n. 3, p. 4-6, 2012.
  96. 96. Referências • McCREARY, Dan; KELLY, Ann. Making Sense of NoSQL: A guide for managers and the rest of us. Manning Publications Co.. 2013 • MÜLLER, Stephan. The CAP-Theorem & Yahoo’s PNUTS. 2012. • O'GRADY, Stephen. The New Kingmakers. O'Reilly Media, 2013. • PARTNER, Jonas. Neo4j in Action. Manning Publications Co., 2013. • PRITCHETT, Dan. Base: An acid alternative. Queue, v. 6, n. 3, p. 48-55, 2008.
  97. 97. Referências • ROBINSON, Ian; WEBBER, J.; EIFREM, E. Graph Databases. O'Reilly Media, 2013. • SADALAGE, Pramod J.; FOWLER, Martin. NoSQL distilled: a brief guide to the emerging world of polyglot persistence. Addison-Wesley, 2012. • TIWARI, Shashank. Professional NoSQL. John Wiley & Sons, 2011. • VOGELS, Werner. Eventually consistent. Communications of the ACM, v. 52, n. 1, p. 40-44, 2009.
  98. 98. Referências • VOGELS, Werner. Eventually consistent - revisited. 2008-12-22. http://www. allthingsdistributed. com/2008/12/eventually_consistent. html, 2008.

×