O documento discute o movimento NoSQL e bancos de dados orientados a documentos. Ele resume brevemente a história dos bancos de dados, caracteriza o movimento NoSQL e seus modelos de dados, como chave-valor, grafos, documentos e colunas. Explica conceitos-chave como escalabilidade, persistência e distribuição em bancos NoSQL. Por fim, faz uma análise comparativa entre bancos de dados relacionais e não relacionais, com foco no CouchDB como exemplo de banco orientado a documentos.

1. O Movimento NOSQL e osBancos de Dados OrientadosàDocumentos yuriadams@triadworks.com.br @yuriadams yuriadamsmaia.wordpress.com

2. #whoami Yuri Adams Chaves Maia CursandoCiências da Computação – UECE Estagiário da TriadWorks Agile Software Development.

3. #whoami

4. #whoami Treinamentos Desenvolvimento Mentoring

5. #tecnologias

6. Networking

7. Elesvãoticonhecer!

8. Tietagem

9. Followers!!!

10. #whoami @yuriadams yuriadams@gmail.com / yuriadams@triadworks.com.br yuriadamsmaia@wordpress.com

11. Me tucutem!!

12. #merchan

13. #motivacao

14. Tópicos NOSQL? BreveHistórico Movimento NOSQL Características Modelos de Dados (Famílias de BDs)

15. NOSQL?

16. NOSQL?

17. NOSQL?

18. Histórico “Aquelesquenãopodemlembrar o passado, estãocondenados a repetí-lo”

19. Histórico

20. Histórico IMS-DB – ModeloHierárquico – Década de 60 CODASYL - anos1970 – Grafo BancosRelacionais – Década de 80 - * Nada de novo? Nenhumaalternativa?

21. Histórico

22. Histórico

23. Movimento NOSQL 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 not only SQL – termoparadescreversoluções de armazenamento de dados nãorelacionais.

24. Movimento NOSQL

25. NOSQL nãoébala de prata!

26. Características + Propriedades ACID X BASE A = Atomicidade C = Consistência I = Isolamento D = Durabilidade Sempreépossível? Seriabom se fosse.

27. Características + Propriedades ACID X BASE Simplificar a arquitetura Performance BA = Basically Available S = Soft-state E = Eventual consistency * *Eventual = Uma horairáocorrer.

28. BASE TransaçãoBancária Cliente Banco transfere Estaráincosistenteaté o bancoautorizar ContaDestino

29. Características + Propriedades Abrirmão da consistênciaem favor da disponibilidade e escalabilidade

30. Escalabilidade Big Data

31. Escalabilidade Big Data

32. Escalabilidade Big Data 7 TB diários

33. Escalabilidade Big Data Clusters

34. Escalabilidade Escalabilidade Horizontal X Escalabilidade Vertical Escalabilidade Vertical upgrades SERVER APP

35. Escalabilidade Escalabilidade Horizontal X Escalabilidade Vertical Escalabilidade Horizontal

36. Persistência Relacionais => Disco => Durabilidade  - Confiabilidade ----  Desempenho Memory-mapped => Memória/Arquivo  - Ganhoemdesempenho --  MemóriaVolátil

37. Persistência

38. Persistência

39. Distribuição Caminha com a escabilidade horizontal PARTICIONAMENTO: EvitarPerda de Informação – distribuiros dados emmais de um servidor *Nosql Relacional  *Modelosbaseadosemgrafostambémháperda.

40. Modelo de Dados

41. Modelo de Dados Chave-Valor Grafo OrientadosàDocumentos Família de Colunas

42. Chave-Valor Semelhante a estruturaHashMap

43. Chave-Valor Semelhante a estruturaHashMap  Simplicidade Consultas O(1) – independente do volume de dados

44. Chave-Valor Semelhante a estruturaHashMap  Complexidade no momento de formular as chaves Obterapenas um valor porchave

45. Chave-Valor

46. Redis Desenvolvidopor: Salvatore Sanfilippo -2009 ANSI-C Utiliza a memória RAM comomeio de Alocação de Dados Nãoestádesenvolvido o recurso de cluster

47. Grafo PossuiPropriedades ACID  Perca de Rendimento

48. Grafo

49. Neo4J Desenvolvidoem 2003 – Neo Technology Possuibeneficios dos modelosbaseadosemgrafos. JAVA

50. Orientados `a Documentos Documentos?

51. Orientados `a Documentos Documentos? Estrutura de Dados de tiposvariáveispodendohaver sub-documentos.

52. Orientados `a Documentos

53. Orientados `a Documentos Documentos? Estrutura de Dados de tiposvariáveispodendohaver sub-documentos. JSON Desnormalização

54. Orientados `a Documentos

55. Orientados `a Documentos

56. CouchDB “Cluster of Unreliable Commodity Hardware” Inicialmenteem C++  Erlang (2008) Tolerância a falhas e facilidade com programaçãodistribuída. Liceça Apache v2.0

57. Família de Colunas BigTable e seusDerivados => Paper de 2006 Escalabilidade + Volume de Dados

58. Família de Colunas

59. Família de Colunas Keyspaces => Databases/Schema Família de Colunas => Tabelas Colunas => Registros * Chave-valor Turbo POWER!!

60. Família de Colunas

61. Família de Colunas  Adequação de velocidade x escalabilidade  Complexidadena forma de armazenar

62. Família de Colunas

63. Cassandra Nasceudentro do Facebook(2008) Licença Apache (2009) JAVA – Executaemqualquerplataforma  Nãopossuiuma interface amigável

64. Banco de Dados OrientadosàDocumentos

65. Banco de Dados OrientadosàDocumentos Entender o modelo de dados, a forma comosãorepresentados e armazenadososregistros Compreendercomoos dados sãorecuperados e consultados

66. Banco de Dados OrientadosàDocumentos

67. CouchDB Schema Free

68. CouchDB Schema Free WEB

69. CouchDB Schema Free WEB API REST JSON

70. CouchDB Schema Free WEB API REST JSON Futon(APP Admin)

71. Documentos Como sãoformatados?

72. JSON

73. JSON JSON  JAVASCRIPT OBJECT NOTATION

74. JSON - Estrutura Objeto: suarepresentaçãoéfeitaatravés de chaves. Exemplo: {} ou { membros }; Pares: sãoos pares chave/valor, definidoscomouma string e um valor. Exemplo de umaexpressão: “nome” : “Yuri Adams”; Membros: Um oumais pares de chave/valor; Array: sãolistas de elementos, podemsermultidimensionais. Exemplo: [ { “chave”: “valor” }, 1234 ] array de um par e um valor, ambos são elementos; Valor: sãoostipos de dados que o JSON podeassumir: string, numérico, objeto, array, true, false ounull.

75. JSON

76. JSON

77. PropriedadesTransacionais

78. PropriedadesTransacionais

79. PropriedadesTransacionais

80. PropriedadesTransacionais

81. Administração Futon

82. Administração Futon APIS com implementaçãoem Ruby(couchrest_model), Python, Java(jcouchdb)

83. Administração

84. Administração Futon APIS com implementaçãoem Ruby(couchrest_model), Python, Java(jcouchdb) Browsers queinterpretemfunçõesjavascript. AJAX (chamadasassícronas)

85. BDOD X SGBDRs

86. Modelagem de Dados

87. Modelagem de Dados

88. Estado Global Sequences

89. Estado Global

90. Estado Global UUID (Identificadoresúnicosglobais)

91. Arquitetura RESTful Cliente/Servidor

92. Arquitetura .Stateless (like WEB)

93. Qual a vantagem?

94. Arquitetura Cacheable (Jáembutido no HTTP)

95. Cacheable CLIENTE BDOD SERVIDOR REQUEST RESPONSE

96. Cacheable CLIENTE BDOD SERVIDOR REQUEST RESPONSE

97. Interface Uniforme REST + URI

98. JOINS FOREIGN KEYS

99. JOIN FOREIGN KEYS

100. JOIN

101. Map/Reduce

102. Map/Reduce

103. Map/Reduce

104. REST REPRESENTATIONAL STATE TRANSFER Por Fielding: “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”

105. REST REPRESENTATIONAL STATE TRANSFER PorTilkov: “um conjunto de princípiosquedefinemcomoospadrões Web, como o HTTP e URIs devemserutilizados”

106. REST REPRESENTATIONAL STATE TRANSFER Por Yuri: “Sei o queé,sónãoseiexplicar”

107. Recurso A WEB como um conjunto de Recursos.

108. Recurso?

109. Recurso “link” paraumainformaçãoespecífica URI (Universal Resource Identifier)

110. Recurso “link” paraumainformaçãoespecífica URI (Universal Resource Identifier)

111. URI

112. URI

113. URI

114. HTTP

115. Interface de Consultas Verbos HTTP + URI Seleção Inserção Atualização Remoção

116. SELECT

117. SELECT

118. Insert

119. Insert

120. Update

121. Update

122. Delete

123. Delete

124. Views

125. Views

126. Atéqueenfim!!! OBRIGADO!! @yuriadams yuriadams@gmail.com