- 1. NoSQL
2. Rafael Benedito
3. Aviso!
- O que voc vai ver/aprender nessa apresentao: 4. Conceitos de
banco de dados NoSQL; 5. Taxonomia de banco de dados NoSQL; 6.
Conceitos de Banco de Dados distribudos; 7. Comparaes entre Bancos
RDBMS e NoSQL; 8. Exemplos de banco de dados NoSQL; 9. Mitos sobre
bancos NoSQL; 10. O que voc no vai ver/aprender nessa apresentao:
11. Implementao de algum banco NoSQL; 12. Dominar o mundo; 13.
Ficar rico;
14. O que essas empresas tem em comum ? 15.
- Quando voc digita pindamonhangaba no google, e ele traz:
"Aproximadamente 20.500.000 resultados (0,15 segundos)", ANTES DE
VOC TERMINAR DE DIGITAR, voc acha que ele est fazendo um SQL like
em um ndice???
16. 17. O que NoSQL ? de comer ? 18.
- NO SQL/N o tO nlySQL(No apenas SQL)
- NO SQL/N o tO nlySQL 19. No apenas SQL 20. Diferentes sistemas
de armazenamento de 21. dados para resolver problemas em que os 22.
RDBMS no so a melhor soluo 23. Algo em torno de 10% dos casos 24.
Hype: alta escalabilidade
25. Um pouco de histria
- Cinco NECESSIDADES do mercado, NO SO ATENDIDAS a contento pelos
produtos de banco de dados e fornecedores disponveis, so elas:
- 1. Escalabilidade 26. 2. Performance 27. 3. Consistncia
Eventual ou Relaxada 28. 4. Agilidade 29. 5. Complexidade
30. Um pouco de histria
- 1. BigTable: A Distributed Storage System for Structured Data
- 1. Publicado pelo Google; 31. 2. Em Novembro de 2006; 32. 3. No
17 simpsio em design e implementao de sistemas operacionais;
- 2. Dynamo: Amazons Highly Available Key-Value Store
- 1. Publicado pela Amazon; 33. 2. Em Outrubro de 2007; 34. 3. No
12 simpsio em princpios de sistemas operacionais ;
35. Prncipais Caractersticas NoSQL
- Escalabilidade Horizontal 36. Replicao 37. Schema-free 38.
Clusterizao 39. MapReduce 40. Sharding
41.
- Escalabilidade Horizontal
- Escalabilidade Horizontal (scale out)significa adicionar mais
ns ao sistema, tais como adicionar um novo servidor e um sistema de
software que permita a distribuio do trabalho entre mltiplas
mquinas.
42.
- Replicao - Escalar por duplicao de informaes
- Consiste na copia das informaes em mais de um banco para
aumentar nossa capacidade de recuperar estas informaes. Podemos
dividir em duas arquiteturas principais:
- Master-Slave: Cada escrita em banco resulta em X escritas onde
X o nmero de slaves. Neste caso temos um banco Master que propaga
cada write para os bancos slaves. Isto aumenta a nossa velocidade
de leitura, mas no melhora a capacidade de escrita. 43.
Multi-Master: Aumentamos o nmero de Masters em nosso sistema e
assim aumentamos nossa capacidade de escrita.
44. Schema-free
- Schema-free: Um dos fatores que contribuem para um banco de
dados 45. NoSQL escalar por causa da ausncia de um schema (schema
free). Todos os novos bancos tem em comum que eles so 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 binrio ou string que est sendo salvo de forma
desnormalizada (schema-free).
46. Clusterizao
- Clusterizao: Basicamente compreende um banco de dados
armazenado e gerenciado por mais de um servidor, prov uma alta
disponibilidade e um alto desempenho do sistema. Assim, a organizao
se beneficia diminuindo o tempo de inoperabilidade do banco de
dados. Esse processo vem como uma soluo para reduzir gastos com
estrutura de hardware.
47. Mapreduce
- Mapreduce: um algoritmo, patenteado pela Google para
gerenciamento em larga escala. Existem duas fases:
- Map: O n principal recebe os dados, divide e partes menores e
as envia aos outros ns para serem processados. Ao final do
processamento estes ns devolvem o resultado ao n principal. 48.
Reduce: O n principal combina as respostas obtidas pelos outros ns
gerando o resultado final do processamento.
49. 50. Sharding
- Sharding: Consiste em dividir os dados horizontalmente, ou
seja, quebrar as tabelas, diminuindo o seu nmero de linhas e
separando-as em ambientes diferentes. Neste ponto todos os dados de
uma partio no devem conter referncias aos dados de outras parties,
sendo que os dados em comum devero ser replicados entre as
bases.
51. 52. Categorias do NOSQL 53. Key-value(Chave-Valor)
- Focado em escalabilidade para grandes quantidades de dados; 54.
Projetado para ligar com grande carga de dados; 55. Baseado no
Amazon's Dynamo paper; 56. Modelo de dados:(Global) coleo de pares
chave-valor 57. Anel Dynamo de particionamento e replicao; 58.
Exemplos:
- Dynomite 59. Voldemort 60. Tokyo
61. 62. Big Table clones
- Como bancos de dados relacionais orientado a colunas, mas com
twist(toque); 63. Tabelas similares aos RDBMS, mas de forma
semi-estruturada; 64. Baseado no Google's BigTable paper; 65.
Modelo de dados:Colunas -> Familias de colunas -> ACL
- Datas chaveados por: linha, coluna, tempo , ndice 66. Row-range
-> tabela -> distribuio
- Exemplos:
- Hbase 67. Hyperbase 68. Cassandra
69. Document databases
- Similar ao chave-valor, mas o BD sabe qual o valor; 70.
Inspirado pelo Lotus Notes; 71. Modelo de dados: Colees de colees
chaves-valor; 72. Documentos so frequentemente versionados; 73.
Exemplos:
- CouchDB 74. MongoDB 75. Redis
76. Graph databases
- Focado na modelagem de estruturas de dados interconectividade;
77. Escala complexidade dos dados; 78. Inspirado no teorema
matemtico dos Grafos(G=(E,V)); 79. Modelo de dados: Propriedade
Grafo Ns
- Relacionamentos entre ns (primeira classe); 80. Pares de
chaves-Valores em ambos;
- Examples
82. 83. Uma breve pausa.
- Teoria dos grafos 84. A teoria dos grafos um ramo da matemtica
que estuda as relaes entre os objetos de um determinado conjunto.
85. Grafo com 4 vrtices e 6 arestas. um grafo completo, conexo e
planar. 86. Grafo uma estrutura G(V,A) onde V um conjunto no vazio
de objetos denominados vrtices e A um conjunto de pares no
ordenados de V, chamado arestas. 87. Dependendo da aplicao, arestas
podem ou no ter direo, pode ser permitido ou no arestas ligarem um
vrtice a ele prprio e vrtices e/ou arestas podem ter um peso
(numrico) associado. Se as arestas tm uma direo associada (indicada
por uma seta na representao grfica) temos um grafo direcionado,
grafo orientado ou digrafo.
88. Exemplificando...
- Grafo com 4 vrtices e 6 arestas. 89. um grafo completo, conexo
e planar.
90. 91. O teorema do Caos, ops CAP :)
- C onsistency (Consistncia)
- Todos os clientes podem ver os mesmos dados.
- A vailability (Disponibilidade)
- Todos os clientes podem sempre acessar os dados
- P artition tolerance (Tolerncia a parties)
- A capacidade de continuar a trabalhar mesmo quando a topologia
de rede quebrada. 92. A capacidade de recuperar quando a rede
volta. 93. Dos 3 se preocupe com somente 2 =)
94. CA: Consistency & Availability
- Tolerncia a partio comprometida; 95. Site clusters simples
(fcil garantir que todos os ns esto sempre em contato); 96. Quando
ocorre uma falha, o sistema bloqueia, por exemplo Two Phase Commit
(2PC);
97. CP: Consistency & Partitioning
- Disponibilidade comprometida; 98. Acesso a alguns dados pode
ser temporariamente limitado; 99. Por exemplo Sharded database
100. AP: Availability & Partitioning
- Consistncia comprometida; 101. Sistema ainda est disponvel sob
particionamento; 102. Alguns dados retornados podem ser
temporariamente no atualizados; 103. Requer uma estratgia de
resoluo de conflitos; 104. Por exemplo, DNS, cache, replicao
master/slave;
105. ACID vs. BASE 106. ACID uma rpida recapitulao
- A tomicidade
- Quando uma parte da transao falhar, toda a transao falha; 107.
O estado do BD inalterado;
- C onsistncia
- Uma transao leva o banco de dados de um estado consitente para
outro;
- I solamento
- Uma transao no pode ler o estado sujo de outras transaes (no
pegar lixo)
- D urabilidade
- Commit significa commit. (Comitou, comitou!)
108. BASE
- O complemento CAP para oACID
- S que tinha que ser chamado BASE =)
- B asicallyA vailable (Basicamente disponvel) 109. S oft State
(Estado suave) 110. E ventually Consistent (Consistncia
eventual)
111.
- RDBMS & ACID / NoSQL & BASE
- RDBMSs se esforam para garantir ACID
- Solues NoSQL muitas vezes escalam atravs de BASE
- BASE aceita que os conflitos vo acontecer
112. Comparaes 113. Comparando estrutura de Dados
- RDBMS
- Banco de Dados contm tabelas, colunas e linhas; 114. Todas as
linhas com a mesma estrutura; 115. Incompatibilidade inerente com
ORM(Mapeamento objeto-relacional)
- NoSQL
- Escolha a sua estrutura de Dados; 116. Os dados so armazenados
na estrutura natural (por exemplo, documentos, grficos,
objetos)
117. Comparando Flexibilidade de Schema
- RDBMS
- Esquema rigoroso, difcil de evoluir 118. Mantm relaes e fora a
integridade de dados
- NoSQL
- Estruturas de dados podem ser alteradas dinamicamente
- Por exemplo Column strores Cassandra
- Os dados podem s vezes ser completamente opacos
- Por exemplo Key/Value Project Voldemort
119. Comparando Normalizao & Relacionamentos
- RDBMS
- O modelo de dados normalizado para remover a duplicao de dados;
120. Normalizao estabelece relaes entre as tabelas
- NoSQL
- Desnormalizao no uma palavra feia 121. Relaes no so
explicitamente definidas 122. Dados relacionados so geralmente
agrupados e armazenados como uma unidade
- Por exemplo, document, column
123. Comparando Acesso Dados
- RDBMS
- Operaes CRUD usando SQL 124. Acesso aos dados de vrias tabelas
usando JOIN 125. API genrica, como JDBC
- NoSQL
- API proprietria e DSLs (por exemplo, Pig/Hive/Gremlin) 126.
MapReduce, Grafos transversais 127. REST APIs, formatos portteis de
serializao
- BSON, JSON, Apache Thrift, Memcached
128. RDMS vs. NoSQL na prtica! 129. Alguns Bancos NoSQL
- Cassandra 130. Hbase 131. Voldemort 132. CouchDB 133. MongoDB
134. Neo4j 135. E muito mais =)
136. Cassandra
- Cassandra um projeto da Apache, que tem como objetivo fornecer
uma soluo escalvel de banco de dados distribudos, emprega
tecnologia do Amazon Dynamo e projetos do Big Table do Google. 137.
Era open-source pelo Facebook em 2008 e foi projetado por um dos
autores originais do Dynamo(Avinash Lakshman), em conjunto com
umengenheiro do Facebook Prashant Malik. 138. Ele usado por muitas
grandes empresas, como Rackspace, Digg, Facebook, Twitter, e Cisco.
139. O servidor de maior produo tem mais de 150 TB de dados. 140.
Cassandra est disponvel sob a licena Apache 2.0.
141. Caractersticas-chave:
- Descentralizado: Todos os ns so iguais; no existe um ponto nico
de falha. 142. Tolerncia a falhas: Dados so automticamente
replicados para mltiplos ns para tolerar falhas;
- Suporte para replicao entre vrios data centers; 143. O n falho
pode ser substitudo sem deixar o sistema inativo.
- Eventualmente consistente: Dados eventualmente usam um modelo
consistente, com otimizaes sugeridas como Hinted Handoff e Reparo
de leitura para minimizar a inconsistncia das janelas. 144.
Elasticidade: Novas mquinas podem ser adicionadas dinamicamente sem
deixar o sistema inativo, operaes de leitura/escrita escalam
linearmente quando um novo servidor adicionado.
145.
- Rico modelo de dados: os registros mais complexos so suportados
como simples key-values stores; 146. Performance comparado ao
MySQL.
- MySQL > 50 GB Data 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
152.
- Cassandra escrito em Java. 153. Utiliza a estrutura de servios
Apache Thrift para fornecer acesso em vrias linguagens. Baseado em
suas razes ele enfatiza a plataforma linux, mas pode ser usado no
windows tambm. 154. Em meados de maro de 2010, Cassandra foi movido
de um projeto de incubadora para um projeto de nvel superior.
Consequentemente, agora tem sua prpria pgina web de nvel
superior:http://cassandra.apache.org . 155. Cassandra muito ativo e
vem progredindo rapidamente.
156. HBase (Apache)
- HBase um banco de dados colunar big table, modelado a partir do
BigTable do Google e construdo em cima do framework Apaches Hadoop.
Ainda muito novo, verso atual 0.90x. HBase suporta tabelas
extremamente grandes e princpios de banco de dados distribudos
como:
- Armazenamento elstico (adio dinmica de novos servidores) 157.
Nenhum ponto nico de falhas 158. Suporte para processamento
MapReduce 159. Servios implantados com o Apache Thrift 160.
REST-ful web service gateway
161.
- Hadoop usado por pesquisas Yahoo , Facebook, Bing Microsoft , e
outros grandes fornecedores. Hadoop e HBase so projetos de cdigo
aberto Apache, e ambos so oferecidos pela Amazon Web Services
atravs da sua oferta de Amazon (AWS). 162. HBase um banco de dados
colunar projetado para escala em todas as direes: milhares de
milhes de linhas, cada uma das quais pode ter milhes de colunas.
Cada interseo de linha / clula uma clula que pode ser versionado. O
nmero de verses armazenadas configurvel.
163.
- Cada tabela Hbase nomeada. As linhas so classificadas por Ids
de linha, que um valor definido pela matriz de bytes do usurio. As
tabelas so organizadas em regies, que so armazenadas separadamente.
Quando uma regio fica cheia, ela se divide e algumas linhas so
movidas. Cada regio tem Ids de linha definidos por [primeira linha,
ltima linha]. 164. As colunas so organizadas em familias de colunas
, que devem ser declaradas. Por exemplo, uma coluna da famila estao
pode ser declarada, posteriormente um aplicativo pode adicionar
valores com os nomes das colunas como estao:id,
estao:nome,estao:descrio, etc.
165.
- Hbase usa o framework Apache Zookeeper para acesso distribudo.
Quando mapeado para o Hadoop HDFS, Hbase implementa uma classe de
arquivo especial que fornece recursos como compresso e filtros.
Compresso GZIP usada por padro, mas compresso LZO pode ser
instalado no Hbase para uma compresso mais rpida e em tempo real.
166. Hbase, como grande parte do Hadoop escrito em Java e enfatiza
o uso em plataformas linux, mas funciona tambm no windows.
167. Voldemort (Open Source)
- O banco de dados Voldemort foi construdo pelo Linkedin para as
suas necessidades. 168. um key/value store que utiliza princpios
Dynamo para processamento distribudo, replicao e tolerncia 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 no suporta diretamente relacionamentos. Alm disso, as
relaes 1-para-muitos devem ser tratadas usando um Mapa incorporado
(Ex: java.util.HashMap) como um valor.
171.
- Os projetistas afirmam que esse design simplista uma vantagem j
que o desempenho muito previsvel. 172. Voldemort teve recentemente
seu cdigo aberto e esta disponvel sob licena 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.
174.
- A arquitetura de Voldemort emprega uma camada distinta para
resolver cada funo lgica: a resoluo de conflitos de serializao,
etc. Isto ilustrado abaixo:
175.
- Como mostrado, Voldemort requer um mecanismo de armazenamento,
como Berkeley DB ou MySQL. Vrias opes de arquitetura fsica esto
disponveis para apoiar vrios balanceamentos de carga e metas de
desempenho. Isso mostrado abaixo:
176.
- A API nativa de Voldemort Java, mas o acesso tambm possvel via
HTTP. 177. Porque o cdigo do Voldemort s foi aberto recentemente
sua vantagem de adoo em relao a outras opes no clara. A sua
dependncia da BDB ou MySQL como uma backend store limita seu uso
para aplicaes comerciais.
178. CouchDB (Apache)
- CouchDB um banco de dados orientado a documentos, muitas vezes
foi chamado de banco de dados orientado a documentos garoto
propaganda. um ad-hoc, esquema de banco de dados flexvel com espao
de armazenamento plano. Escrito em Erlang, CouchDB pode ser
consultado e indexado usando expresses MapReduce. Ele suporta JSON
e um acesso estilo REST.
179.
- Uma viso geral de sua arquitetura a partir do site da Apache
mostrada abaixo:
180.
- CouchDB usa incrementao, replicao assncrona com deteco de
conflitos e de gerenciamento. A arquitetura multi-master permite
que um master pode ficar off-line (escritas ficam na fila at que o
master fique online). 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, nmeros, datas ou at mesmo
listas ordenadas e mapas associativos.
182.
- Um exemplo de um documento um post: 183. Um banco de dados
CouchDB uma coleo plana destes documentos, cada documento
identificado por um ID nico. Pesquisa de texto completo fornecido
por um ndice Lucene. ndices adicionais so vises definidas usando o
padro MapReduce e JavaScript para mtodos. (Essa abordagem tem sido
descrito como "estranho".)
184.
- Emil Eifrm e Adam Skogman descrevem CouchDB como sendo difcil
de usar. Outras pesquisas internas em Quest tambm categorizam como
um banco de dados de propsito especfico. 185. CouchDB parece ser um
dos primeiros exemplos de um DB documento e melhor usado para
aplicaes que necessitam especificamente dessa funcionalidade.
186. MongoDB (Open Source)
- MongoDB um sistema de banco de dados orientado a documentos
escrito em C++ uma vez foi descrito como CouchDB sem as loucuras.
No seu site definido como escalvel, de alta performance, open
source, livre de esquemas, orientado a documentos. Principais
caractersticas:
- Armazenamento orientado a documentos(a simplicidade e o poder
de esquemas JSON como dados) 187. Consultas dinmicas
188.
- Suporte completo para ndices, exetendendo-se at inner-objects e
arrays embutidos 189. Perfil de consulta 190. Rpido, nas atualizaes
locais 191. Armazenamento eficiente de objetos de dados binrios(Ex:
fotos e videos) 192. Replicao sem falhas 193. Auto-sharding para
nveis escalveis de nuvens
194.
- MapReduce para agregaes complexas 195. Suporte comercial,
treinamento e consultoria 196. Acesso programtico est disponvel em
diversar linguagens como C, C++, C#, Erlang, Java, Python, Ruby, e
muito mais.
197. Neo4j (Neo Technologies)
- Neo4j um banco de dados orientado a grafos para aplicaes
embarcadas. escrito em Java, mas tem clientes para Python, Ruby,
Clojure, and Scala. Ele suporta transaes ACID e fornece replicaes
master-slave. fornecido pela Neo Technologies e tem ambas as
licenas, AGPL e Comercial. O arquivo JAR do Neo4J tem apenas 500kb,
e supostamente suporta bilhes de ns, relacionamentos e propriedades
em um nico sistema.
198.
- Um exemplo de um grafo tpico de informao mostrado abaixo:
199.
- Uma referncia a Neo4j sugeriu que havia suporte muito bsico de
replicao master/slave, mas feito aparentemente atravs de um
mecanismo muito suave, como um replicador de disco. Menes de
sharding tambm so feitas, mas um post no blog explica que este deve
ser feito essencialmente no cliente. Como resultado, o suporte
embutido a escalabilidade parece ser limitado,e pode ser feito em
uma nica mquina. 200. A falta de estratgia de escalabilidade, o
foco em um modelo de grafo, e a necessidade de uma licena comercial
parecem fazer Neo4j de uso limitado.
201. Os maiores mitos sobre NoSQL
- NoSQL escalvel 202. No precisamos de DBAs 203. NoSQL mais
econmico
204.
- Uma das grandes promessas dos bancos NOSQL consiste em dizer
que eles so mais escalveis que os bancos de dados relacionais. O
problema com esta mensagem que vendida por algumas empresas que ela
no inteiramente verdade. Dizer que seu sistema escala sozinho
vender um sonho. Ele pode at ser mais fcil de escalar se comparado
a outras solues mas ainda sim exigira algum esforo para
escalar.
205.
- No mundo dos bancos relacionais a figura do DBA sempre est
presente. Com sistemas que tem particularidades para cada vendor os
DBAs ficam a cargo de instalar, configurar e manter cada banco de
dados em suas particularidades. Muita gente diz que quando se
trabalha com NoSQL no precisamos de DBAs. Acredito que talvez no no
sentido tradicional, mas ainda vamos precisar de algum responsvel
por lidar com o banco e com o acesso aos dados. Esta funo pode vir
a se tornar parte do trabalho de um desenvolvedor ou se tornar a
funo full time de algum no seu time que pode ser at um DBA com
conhecimentos em NoSQL. Em aplicaes reais em produo muito
provavelmente ser necessrio misturar bancos relacionais e no
relacionais, possuir algum que navegue facilmente nos dois mundos
em seu time uma grande vantagem.
206. NoSQL mais econmico
- Meia verdade. Muitos fornecedores de NoSQL afirmam que suas
solues vo baratear o custo dos seus clientes. Em parte sim, em
algumas situes o custo em usar um banco de dados relacional pode
ser proibitivo devido a escala ou a licenas envolvidas. Existem
muitos casos entretanto que uma soluo relacional atende
perfeitamente todas as necessidades do cliente e ainda sim pode ser
considerada barata. Bancos de dados open source como MySQL e
PosgreSQL so usados sem problemas por um grande nmero de aplicaes
com sucesso.
207.
208. Obrigado! 209.
- http://nosql.findthebest.com/d/l/Open-Source 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/