no sql std

1. NoSQL

Arthur Azevedo

2. Rafael Benedito

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;

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???

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

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

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 ;

Escalabilidade Horizontal 36. Replicao 37. Schema-free 38. Clusterizao 39. MapReduce 40. Sharding

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.

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.

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).

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.

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.

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.

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

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

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

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

Neo4j 81. AllegroGraph

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.

Grafo com 4 vrtices e 6 arestas. 89. um grafo completo, conexo e planar.

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 =)

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);

Disponibilidade comprometida; 98. Acesso a alguns dados pode ser temporariamente limitado; 99. Por exemplo Sharded database

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;

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!)

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)

RDBMS & ACID / NoSQL & BASE

RDBMSs se esforam para garantir ACID

ACID fora a consistncia

Solues NoSQL muitas vezes escalam atravs de BASE

BASE aceita que os conflitos vo acontecer

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)

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

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

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

Cassandra 130. Hbase 131. Voldemort 132. CouchDB 133. MongoDB 134. Neo4j 135. E muito mais =)

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.

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.

Rico modelo de dados: os registros mais complexos so suportados como simples key-values stores; 146. Performance comparado ao MySQL.

Por exemplo:

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

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.

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

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.

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.

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.

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.

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.

A arquitetura de Voldemort emprega uma camada distinta para resolver cada funo lgica: a resoluo de conflitos de serializao, etc. Isto ilustrado abaixo:

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:

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.

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.

Uma viso geral de sua arquitetura a partir do site da Apache mostrada abaixo:

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.

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".)

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.

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

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

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.

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.

Um exemplo de um grafo tpico de informao mostrado abaixo:

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.

NoSQL escalvel 202. No precisamos de DBAs 203. NoSQL mais econmico

NoSQL escalvel

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.

No precisamos de DBAs

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.

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.

Dvidas?

Referncias:

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/

no sql std

Documents