Nosql e BD Orientados a Documentos

2.865 visualizações

Publicada em

Publicada em: Educação
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
2.865
No SlideShare
0
A partir de incorporações
0
Número de incorporações
5
Ações
Compartilhamentos
0
Downloads
60
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Nosql e BD Orientados a Documentos

  1. 1. O Movimento NOSQL e osBancos de Dados OrientadosàDocumentos<br />yuriadams@triadworks.com.br<br />@yuriadams<br />yuriadamsmaia.wordpress.com<br />
  2. 2. #whoami<br />Yuri Adams Chaves Maia<br />CursandoCiências da Computação – UECE<br />Estagiário da TriadWorks Agile Software Development.<br />
  3. 3. #whoami<br />
  4. 4. #whoami<br />Treinamentos<br />Desenvolvimento<br />Mentoring<br />
  5. 5. #tecnologias<br />
  6. 6. Networking<br />
  7. 7. Elesvãoticonhecer!<br />
  8. 8. Tietagem<br />
  9. 9. Followers!!!<br />
  10. 10. #whoami<br />@yuriadams<br />yuriadams@gmail.com / yuriadams@triadworks.com.br<br />yuriadamsmaia@wordpress.com<br />
  11. 11. Me tucutem!!<br />
  12. 12. #merchan<br />
  13. 13. #motivacao<br />
  14. 14. Tópicos<br />NOSQL?<br />BreveHistórico<br />Movimento NOSQL<br />Características<br />Modelos de Dados (Famílias de BDs)<br />
  15. 15. NOSQL?<br />
  16. 16. NOSQL?<br />
  17. 17. NOSQL?<br />
  18. 18. Histórico<br />“Aquelesquenãopodemlembrar o passado, estãocondenados a repetí-lo”<br />
  19. 19. Histórico<br />
  20. 20. Histórico<br />IMS-DB – ModeloHierárquico – Década de 60<br />CODASYL - anos1970 – Grafo<br />BancosRelacionais – Década de 80 - *<br />Nada de novo? Nenhumaalternativa?<br />
  21. 21. Histórico<br />
  22. 22. Histórico<br />
  23. 23. Movimento NOSQL<br />O movimentonoSQLtevesuaorigememjunho de 2009, paranomear um encontropromovidopor Johan Oskarsson e Eric Evans, quetevecomoobjetivodiscutir o crescentesurgimento de soluçõesopen source de armazenamento de dados distribuídosnãorelacionais<br />not only SQL – termoparadescreversoluções de armazenamento de dados nãorelacionais.<br />
  24. 24. Movimento NOSQL<br />
  25. 25. NOSQL nãoébala de prata!<br />
  26. 26. Características + Propriedades<br />ACID X BASE<br />A = Atomicidade<br />C = Consistência<br />I = Isolamento<br />D = Durabilidade<br />Sempreépossível? Seriabom se fosse.<br />
  27. 27. Características + Propriedades<br />ACID X BASE<br />Simplificar a arquitetura<br />Performance<br />BA = Basically Available<br />S = Soft-state<br />E = Eventual consistency *<br />*Eventual = Uma horairáocorrer.<br />
  28. 28. BASE<br />TransaçãoBancária<br />Cliente<br />Banco<br />transfere<br />Estaráincosistenteaté o bancoautorizar<br />ContaDestino<br />
  29. 29. Características + Propriedades<br />Abrirmão da consistênciaem favor da disponibilidade e escalabilidade<br />
  30. 30. Escalabilidade<br />Big Data<br />
  31. 31. Escalabilidade<br />Big Data<br />
  32. 32. Escalabilidade<br />Big Data<br />7 TB diários<br />
  33. 33. Escalabilidade<br />Big Data<br />Clusters<br />
  34. 34. Escalabilidade<br />Escalabilidade Horizontal X Escalabilidade Vertical<br />Escalabilidade Vertical<br />upgrades<br />SERVER<br />APP<br />
  35. 35. Escalabilidade<br />Escalabilidade Horizontal X Escalabilidade Vertical<br />Escalabilidade Horizontal<br />
  36. 36. Persistência<br />Relacionais => Disco => Durabilidade<br /> - Confiabilidade ----  Desempenho<br />Memory-mapped => Memória/Arquivo<br /> - Ganhoemdesempenho --  MemóriaVolátil<br />
  37. 37. Persistência<br />
  38. 38. Persistência<br />
  39. 39. Distribuição<br />Caminha com a escabilidade horizontal<br />PARTICIONAMENTO:<br />EvitarPerda de Informação – distribuiros dados emmais de um servidor<br />*Nosql Relacional  <br />*Modelosbaseadosemgrafostambémháperda.<br />
  40. 40. Modelo de Dados<br />
  41. 41. Modelo de Dados<br />Chave-Valor<br />Grafo<br />OrientadosàDocumentos<br />Família de Colunas<br />
  42. 42. Chave-Valor<br />Semelhante a estruturaHashMap<br />
  43. 43. Chave-Valor<br />Semelhante a estruturaHashMap<br /><br />Simplicidade<br />Consultas O(1) – independente do volume de dados<br />
  44. 44. Chave-Valor<br />Semelhante a estruturaHashMap<br /><br />Complexidade no momento de formular as chaves<br />Obterapenas um valor porchave<br />
  45. 45. Chave-Valor<br />
  46. 46. Redis<br />Desenvolvidopor: Salvatore Sanfilippo -2009<br />ANSI-C<br />Utiliza a memória RAM comomeio de Alocação de Dados<br />Nãoestádesenvolvido o recurso de cluster<br />
  47. 47. Grafo<br />PossuiPropriedades ACID <br />Perca de Rendimento<br />
  48. 48. Grafo<br />
  49. 49. Neo4J<br />Desenvolvidoem 2003 – Neo Technology<br />Possuibeneficios dos modelosbaseadosemgrafos.<br />JAVA<br />
  50. 50. Orientados `a Documentos<br />Documentos?<br />
  51. 51. Orientados `a Documentos<br />Documentos?<br />Estrutura de Dados de tiposvariáveispodendohaver sub-documentos.<br />
  52. 52. Orientados `a Documentos<br />
  53. 53. Orientados `a Documentos<br />Documentos?<br />Estrutura de Dados de tiposvariáveispodendohaver sub-documentos.<br />JSON<br />Desnormalização<br />
  54. 54. Orientados `a Documentos<br />
  55. 55. Orientados `a Documentos<br />
  56. 56. CouchDB<br />“Cluster of Unreliable Commodity Hardware”<br />Inicialmenteem C++  Erlang (2008)<br />Tolerância a falhas e facilidade com programaçãodistribuída.<br />Liceça Apache v2.0<br />
  57. 57. Família de Colunas<br />BigTable e seusDerivados => Paper de 2006<br />Escalabilidade + Volume de Dados<br />
  58. 58. Família de Colunas<br />
  59. 59. Família de Colunas<br />Keyspaces => Databases/Schema<br />Família de Colunas => Tabelas<br />Colunas => Registros<br />* Chave-valor Turbo POWER!!<br />
  60. 60. Família de Colunas<br />
  61. 61. Família de Colunas<br /> <br />Adequação de velocidade x escalabilidade<br /><br />Complexidadena forma de armazenar<br />
  62. 62. Família de Colunas<br />
  63. 63. Cassandra<br />Nasceudentro do Facebook(2008)<br />Licença Apache (2009)<br />JAVA – Executaemqualquerplataforma<br /> Nãopossuiuma interface amigável<br />
  64. 64. Banco de Dados OrientadosàDocumentos<br />
  65. 65. Banco de Dados OrientadosàDocumentos<br />Entender o modelo de dados, a forma comosãorepresentados e armazenadososregistros<br />Compreendercomoos dados sãorecuperados e consultados<br />
  66. 66. Banco de Dados OrientadosàDocumentos<br />
  67. 67. CouchDB<br />Schema Free<br />
  68. 68. CouchDB<br />Schema Free<br />WEB<br />
  69. 69. CouchDB<br />Schema Free<br />WEB<br />API REST<br />JSON<br />
  70. 70. CouchDB<br />Schema Free<br />WEB<br />API REST<br />JSON<br />Futon(APP Admin)<br />
  71. 71. Documentos<br />Como sãoformatados?<br />
  72. 72. JSON<br />
  73. 73. JSON<br />JSON  JAVASCRIPT OBJECT NOTATION<br />
  74. 74. JSON - Estrutura<br />Objeto: suarepresentaçãoéfeitaatravés de chaves. Exemplo: {} ou { membros };<br />Pares: sãoos pares chave/valor, definidoscomouma string e um valor. Exemplo de umaexpressão: “nome” : “Yuri Adams”;<br />Membros: Um oumais pares de chave/valor;<br />Array: sãolistas de elementos, podemsermultidimensionais. Exemplo: [ { “chave”: “valor” }, 1234 ] array de um par e um valor, ambos são elementos;<br />Valor: sãoostipos de dados que o JSON podeassumir: string, numérico, objeto, array, true, false ounull.<br />
  75. 75. JSON<br />
  76. 76. JSON<br />
  77. 77. PropriedadesTransacionais<br />
  78. 78. PropriedadesTransacionais<br />
  79. 79. PropriedadesTransacionais<br />
  80. 80. PropriedadesTransacionais<br />
  81. 81. Administração<br />Futon<br />
  82. 82. Administração<br />Futon<br />APIS com implementaçãoem Ruby(couchrest_model), Python, Java(jcouchdb)<br />
  83. 83. Administração<br />
  84. 84. Administração<br />Futon<br />APIS com implementaçãoem Ruby(couchrest_model), Python, Java(jcouchdb)<br />Browsers queinterpretemfunçõesjavascript.<br />AJAX (chamadasassícronas)<br />
  85. 85. BDOD X SGBDRs<br />
  86. 86. Modelagem de Dados<br />
  87. 87. Modelagem de Dados<br />
  88. 88. Estado Global<br />Sequences<br />
  89. 89. Estado Global<br />
  90. 90. Estado Global<br />UUID (Identificadoresúnicosglobais)<br />
  91. 91. Arquitetura<br />RESTful<br />Cliente/Servidor<br />
  92. 92. Arquitetura<br />.Stateless (like WEB)<br />
  93. 93. Qual a vantagem?<br />
  94. 94. Arquitetura<br />Cacheable (Jáembutido no HTTP)<br />
  95. 95. Cacheable <br />CLIENTE<br />BDOD<br />SERVIDOR<br />REQUEST<br />RESPONSE<br />
  96. 96. Cacheable <br />CLIENTE<br />BDOD<br />SERVIDOR<br />REQUEST<br />RESPONSE<br />
  97. 97. Interface Uniforme<br />REST + URI<br />
  98. 98. JOINS<br />FOREIGN KEYS<br />
  99. 99. JOIN<br />FOREIGN KEYS<br />
  100. 100. JOIN<br />
  101. 101. Map/Reduce<br />
  102. 102. Map/Reduce<br />
  103. 103. Map/Reduce<br />
  104. 104. REST<br />REPRESENTATIONAL STATE TRANSFER<br />Por Fielding:<br />“um conjunto de princípiosarquiteturaisquequandoaplicadascomo um todo, enfatiza a escalabilidade da interação entre componentesparareduzir a latência de interação, garantirsegurança e encapsularsistemaslegados”<br />
  105. 105. REST<br />REPRESENTATIONAL STATE TRANSFER<br />PorTilkov:<br />“um conjunto de princípiosquedefinemcomoospadrões Web, como o HTTP e URIs devemserutilizados”<br />
  106. 106. REST<br />REPRESENTATIONAL STATE TRANSFER<br />Por Yuri:<br />“Sei o queé,sónãoseiexplicar”<br />
  107. 107. Recurso<br />A WEB como um conjunto de Recursos.<br />
  108. 108. Recurso?<br />
  109. 109. Recurso<br />“link” paraumainformaçãoespecífica<br />URI (Universal Resource Identifier)<br />
  110. 110. Recurso<br />“link” paraumainformaçãoespecífica<br />URI (Universal Resource Identifier)<br />
  111. 111. URI<br />
  112. 112. URI<br />
  113. 113. URI<br />
  114. 114. HTTP<br />
  115. 115. Interface de Consultas<br />Verbos HTTP + URI<br />Seleção<br />Inserção<br />Atualização<br />Remoção<br />
  116. 116. SELECT<br />
  117. 117. SELECT<br />
  118. 118. Insert<br />
  119. 119. Insert<br />
  120. 120. Update<br />
  121. 121. Update<br />
  122. 122. Delete<br />
  123. 123. Delete<br />
  124. 124. Views<br />
  125. 125. Views<br />
  126. 126. Atéqueenfim!!!<br />OBRIGADO!!<br />@yuriadams<br />yuriadams@gmail.com<br />

×