1) O documento apresenta conceitos sobre bancos de dados NoSQL, incluindo taxonomia, características como escalabilidade horizontal e replicação, e exemplos como Cassandra, HBase e Voldemort. 2) É discutido o teorema CAP e como diferentes bancos de dados NoSQL priorizam disponibilidade, consistência ou tolerância a partições. 3) São feitas comparações entre bancos de dados relacionais e NoSQL, cobrindo estrutura de dados, flexibilidade de esquema, normalização e acesso a dados.

2. Rafael Benedito

4. Conceitos de banco de dados NoSQL;

5. Taxonomia de banco de dados NoSQL;

6. Conceitos de Banco de Dados distribuídos;

7. Comparações entre Bancos RDBMS e NoSQL;

8. Exemplos de banco de dados NoSQL;

9. Mitos sobre bancos NoSQL;

10. O que você não vai ver/aprender nessa apresentação:

11. Implementação de algum banco NoSQL;

12. Dominar o mundo;

13. Ficar rico;

14. O que essas empresas tem em comum ?

17. O que é NoSQL ? É de comer ?

19. Não apenas SQL

20. Diferentes sistemas de armazenamento de

21. dados para resolver problemas em que os

22. RDBMS não são a melhor solução

23. Algo em torno de 10% dos casos

24. Hype: alta escalabilidade

26. 2. Performance

27. 3. Consistência Eventual ou Relaxada

28. 4. Agilidade

29. 5. Complexidade

31. 2. Em Novembro de 2006;

33. 2. Em Outrubro de 2007;

34. 3. No 12º simpósio em princípios de sistemas operacionais ;

36. Replicação

37. Schema-free

38. Clusterização

39. MapReduce

40. Sharding

43. Multi-Master: Aumentamos o número de Masters em nosso sistema e assim aumentamos nossa capacidade de escrita.

45. NoSQL é escalar por causa da ausência de um schema (schema free). Todos os novos bancos tem em comum que eles são key-value stores, ou seja salvam, como o nome sugere, um conjunto de entradas formadas por uma chave associada a um valor e o valor poderia ser de qualquer tipo, um binário ou string que está sendo salvo de forma desnormalizada (schema-free).

48. Reduce: O nó principal combina as respostas obtidas pelos outros nós gerando o resultado final do processamento.

52. Categorias do NOSQL

54. Projetado para ligar com grande carga de dados;

55. Baseado no Amazon's Dynamo paper;

56. Modelo de dados:(Global) coleção de pares chave-valor

57. Anel Dynamo de particionamento e replicação;

59. Voldemort

60. Tokyo

63. Tabelas similares aos RDBMS, mas de forma semi-estruturada;

64. Baseado no Google's BigTable paper;

67. Hyperbase

68. Cassandra

70. Inspirado pelo Lotus Notes;

71. Modelo de dados: Coleções de coleções chaves-valor;

72. Documentos são frequentemente versionados;

74. MongoDB

75. Redis

77. Escala à complexidade dos dados;

78. Inspirado no teorema matemático dos Grafos(G=(E,V));

81. AllegroGraph

84. A teoria dos grafos é um ramo da matemática que estuda as relações entre os objetos de um determinado conjunto.

85. Grafo com 4 vértices e 6 arestas. É um grafo completo, conexo e planar.

86. Grafo é uma estrutura G(V,A) onde V é um conjunto não vazio de objetos denominados vértices e A é um conjunto de pares não ordenados de V, chamado arestas.

87. Dependendo da aplicação, arestas podem ou não ter direção, pode ser permitido ou não arestas ligarem um vértice a ele próprio e vértices e/ou arestas podem ter um peso (numérico) associado. Se as arestas têm uma direção associada (indicada por uma seta na representação gráfica) temos um grafo direcionado, grafo orientado ou digrafo.

89. É um grafo completo, conexo e planar.

92. A capacidade de recuperar quando a rede volta.

93. Dos 3 se preocupe com somente 2 =)

95. Site clusters simples (fácil garantir que todos os nós estão sempre em contato);

96. Quando ocorre uma falha, o sistema bloqueia, por exemplo Two Phase Commit (2PC);

98. Acesso a alguns dados pode ser temporariamente limitado;

99. Por exemplo Sharded database

101. Sistema ainda está disponível sob particionamento;

102. Alguns dados retornados podem ser temporariamente não atualizados;

103. Requer uma estratégia de resolução de conflitos;

104. Por exemplo, DNS, cache, replicação master/slave;

105. ACID vs. BASE

109. S oft State (Estado suave)

110. E ventually Consistent (Consistência eventual)

112. Comparações

114. Todas as linhas com a mesma estrutura;

116. Os dados são armazenados na estrutura natural (por exemplo, documentos, gráficos, objetos)

121. Relações não são explicitamente definidas

124. Acesso aos dados de várias tabelas usando JOIN

126. MapReduce, Grafos transversais

128. RDMS vs. NoSQL na prática!

130. Hbase

131. Voldemort

132. CouchDB

133. MongoDB

134. Neo4j

135. E muito mais =)

137. Era open-source pelo Facebook em 2008 e foi projetado por um dos autores originais do Dynamo(Avinash Lakshman), em conjunto com um engenheiro do Facebook Prashant Malik.

138. Ele é usado por muitas grandes empresas, como Rackspace, Digg, Facebook, Twitter, e Cisco.

139. O servidor de maior produção tem mais de 150 TB de dados.

140. Cassandra está disponível sob a licença Apache 2.0.

144. Elasticidade: Novas máquinas podem ser adicionadas dinamicamente sem deixar o sistema inativo, operações de leitura/escrita escalam linearmente quando um novo servidor é adicionado.

147. Writes Average: ~300 ms

148. Reads Average: ~350 ms

149. Cassandra > 50 GB Data

150. Writes Average: 0.12 ms

151. Reads Average: 15 ms

153. Utiliza a estrutura de serviços Apache Thrift para fornecer acesso em várias linguagens. Baseado em suas raízes ele enfatiza a plataforma linux, mas pode ser usado no windows também.

154. Em meados de março de 2010, Cassandra foi movido de um projeto de incubadora para um projeto de nível superior. Consequentemente, agora tem sua própria página web de nível superior: http://cassandra.apache.org .

155. Cassandra é muito ativo e vem progredindo rapidamente.

157. Nenhum ponto único de falhas

158. Suporte para processamento MapReduce

159. Serviços implantados com o Apache Thrift

160. REST-ful web service gateway

162. HBase é um banco de dados colunar projetado para escala em todas as direções: milhares de milhões de linhas, cada uma das quais pode ter milhões de colunas. Cada interseção de linha / célula é uma célula que pode ser versionado. O número de versões armazenadas é configurável.

164. As colunas são organizadas em familias de colunas , que devem ser declaradas. Por exemplo, uma coluna da familía ”estação” pode ser declarada, posteriormente um aplicativo pode adicionar valores com os nomes das colunas como ”estação:id”, ”estação:nome”,”estação:descrição”, etc.

166. Hbase, como grande parte do Hadoop é escrito em Java e enfatiza o uso em plataformas linux, mas funciona também no windows.

168. É um key/value store que utiliza princípios Dynamo para processamento distribuído, replicação e tolerância a falhas.

169. Pode ser considerado o “Cassandra 1.0” já que o mesmo designer deixou o Linkedin para criar um banco de dados semelhante para o Facebook.

170. Uma vez que o armazenamento é key/value store, Voldemort não suporta diretamente relacionamentos. Além disso, as relações 1-para-muitos devem ser tratadas usando um Mapa incorporado (Ex: java.util.HashMap) como um valor.

172. Voldemort teve recentemente seu código aberto e esta disponível sob licença Apache 2.0.

173. Stemming from the Dynamo research, Voldemort uses “read repair” for conflict detection and resolution instead of two-phase commit or Paxos-style consensus algorithms. This also means that versioning is used and that applications must participate in conflict resolution.

177. Porque o código do Voldemort só foi aberto recentemente sua vantagem de adoção em relação a outras opções não é clara. A sua dependência da BDB ou MySQL como uma backend store limita seu uso para aplicações comerciais.

181. Sob o capô, CouchDB é um armazenamento de chave / valor em que IDs de documentos mapeiam os documentos. Um documento CouchDB é um objeto que consiste em campos nomeados. Valores de campo podem ser strings, números, datas ou até mesmo listas ordenadas e mapas associativos.

183. Um banco de dados CouchDB é uma coleção plana destes documentos, cada documento identificado por um ID único. Pesquisa de texto completo é fornecido por um índice Lucene. Índices adicionais são visões definidas usando o padrão MapReduce e JavaScript para métodos. (Essa abordagem tem sido descrito como "estranho".)

185. CouchDB parece ser um dos primeiros exemplos de um DB documento e é melhor usado para aplicações que necessitam especificamente dessa funcionalidade.

187. Consultas dinâmicas

189. Perfil de consulta

190. Rápido, nas atualizações locais

191. Armazenamento eficiente de objetos de dados binários(Ex: fotos e videos)

192. Replicação sem falhas

193. Auto-sharding para níveis escaláveis de nuvens

195. Suporte comercial, treinamento e consultoria

196. Acesso programático está disponível em diversar linguagens como C, C++, C#, Erlang, Java, Python, Ruby, e muito mais.

200. A falta de estratégia de escalabilidade, o foco em um modelo de grafo, e a necessidade de uma licença comercial parecem fazer Neo4j de uso limitado.

202. Não precisamos de DBAs

203. NoSQL é mais econômico

208. Obrigado!

210. http://pdfcast.org/download/nosql-for-dummies.pdf

211. http://nosql-database.org/

212. http://neo4j.org/

213. http://escalabilidade.com/2010/04/06/introducao-ao-nosql-parte-ii/

214. http://couchdb.apache.org/

215. http://www.mongodb.org/

216. http://cassandra.apache.org/

217. http://nosqlpedia.com/wiki/Survey_distributed_databases#Voldemort_.28Open_Source.29

218. http://blog.linkedin.com/2009/03/20/project-voldemort-scaling-simple-storage-at-linkedin/