Banco de Dados NoSql - JornalJava

2,798 views

Published on

O aumento da modernização das empresas demanda uma crescente criação de sistemas e produção de dados. Para uma empresa com forte dependencia de TI, seus dados se tornam ativos cada vez mais valiosos (e caros) para manter. O acesso, armazenamento e gerenciamento de dados precisa ser encarado como um ponto estratégico para o sucesso dos seus empreendimentos, principalmente quando seu volume de dados já ultrapassou a casa dos PetaBytes.

Algumas empresas de internet enfrentam esses desafios todos os dias, como o Google, Amazon, Ebay, Yahoo, Twitter, Facebook, LinkedIn, etc e o único jeito de sobreviver na web é vencendo essas barreiras, necessitando criar novas estratégias para armazenamento barato para um volume crescente de dados. Dessa necessidade surgiu o conceito de Banco de Dados NoSQL, que difere do conceito comum de banco de dados relacional para um DB mais flexível, focado em escalabilidade horizontal dinâmica e alta disponibilidade com balanceamento automático.

Nessa apresentação será abordado os principais motivadores da utilização dessa abordagem, como ela funciona internamente e como é utilizada pelos maiores sites do planeta.

Published in: Technology
1 Comment
3 Likes
Statistics
Notes
No Downloads
Views
Total views
2,798
On SlideShare
0
From Embeds
0
Number of Embeds
252
Actions
Shares
0
Downloads
0
Comments
1
Likes
3
Embeds 0
No embeds

No notes for slide

Banco de Dados NoSql - JornalJava

  1. 1. Fulvio Longhi<br />@jornaljava<br />Banco de Dados NoSQL Escalabilidade de Dados sem Limites<br />JornalJava.com<br />Fev/2011<br />
  2. 2. Informações<br />Conceito<br />Principais Características<br />Exemplos<br />Quem está Usando?<br />Prós e Contras<br />CAP<br />Tipos de NoSQL DB<br />Principais Produtos<br />Casos Reais<br />Inside NoSQL<br />Referências<br />Perguntas<br />Agenda<br />
  3. 3. A cada ano é criado quase 2x mais dados que o ano anterior (IDC 2007)<br />Grandes sites viram que ACID não escala muito bem<br />99% dos casos de gargalo um sistema pelo IO (seja de rede ou de disco)<br />Algumas Informações<br />
  4. 4. E você acha que tem problemas com dados?<br />Twitter ~ 1,2 milhões ops/sec (2010)<br />Facebook ~ 500 milhões writes/day (2008)<br />Google ~ 1 trilhão de páginas indexadas/day (2010)<br />
  5. 5. NoSQL == “SQL” || “Not Only SQL”<br />NoSQL == NoRDBMS também (geralmente)<br />“ is a term used to designate database management systems that differ from classic relational database management systems in some way. These data stores may not require fixed table schemas, and usually avoid join operations and typically scale horizontally. ” (Wikipedia)<br />Conceito<br />
  6. 6. baixa latência<br />suporte a falhas<br />escalabilidade horizontal e dinâmica<br />alta disponibilidade<br />schemas flexiveis<br />suporte a distribuição geográfica<br />BAIXO CUSTO<br />busca de dados através de heurística<br />meta-index<br />geralmente abrindo mão de:<br />transação, locks, consistência, integridade (tarefas do RDBMS)<br />queries complexas<br />Principais Características<br />
  7. 7. Escalabilidade: característica de aumentar sua capacidade para o seu sistema (seja de processamento, armazenamento ou IO)<br />Escalabilidade Horizontal: escalar adicionando máquinas em paralelo (ex.: Cluster)<br /> desvantagens: sistemas e arquiteturas mais complexas<br />Escalabilidade Vertical: escalar adicionando novos componentes na máquina (ex.: Aumentar memória)<br /> desvantagens: caro, e com limites físicos atingíveis<br />Mas o que é Escalabilidade Horizontal?<br />
  8. 8. sistemas com quantidade de dados massivo<br />arquitetura essencialmente distribuída <br />muitos servidores para suportar um sistema <br />prover resultado de queries impossíveis de serem feitas com joins online<br />sistema com mudanças constantes no schema<br />Exemplos de Utilização<br />
  9. 9. Quem está Usando?<br />
  10. 10. Prós<br />alta disponibilidade<br />escalabilidade horizontal<br />baixo custo<br />expansão dinâmico <br />schemas flexíveis<br />dados distribuídos<br />semi-estruturados<br />Prós e Contras<br />
  11. 11. Contras<br />queries dinâmicas limitadas<br />consistência fica por conta do programa <br />sem padrão<br />sem controle de acesso <br />Prós e Contras<br />
  12. 12. Eric Brewer - Berkeley/MIT, 2000<br />Diagrama CAP<br />
  13. 13. Consistence - após a operação, o dado já está pronto pra consulta<br />todos consultam os mesmos dados<br />Availability - sempre disponível<br />tolerante a falhas de máquinas individuais<br />expansão sem downtime<br />Partition Tolerance - os dados estão espalhados em várias máquinas (não apenas para leitura, mas para escrita também!)<br />Teorema CAP<br />
  14. 14. CA - RDBMS comuns (as vezes em pequenos Clusters)<br />o único meio de escalar é verticalmente<br />CP - Shard (Tabelas particionadas)<br />se uma tabela estiver fora do ar, parte dos dados serão afetados<br />programas mais complexos para manter a consistência<br />AP - DNS, cache, NoSQL<br />difícil manter consistência, resolver conflitos<br />Combinações de CAP<br />
  15. 15. Key/Value - no modelo de Distribuited Hash Table<br />MemCached, Amazon S3, Google Storage, Azure DB, Yahoo Pnuts<br />Column Store - pode-se buscar dados por key:column<br />Apache Cassandra, Apache HBase, Amazon SimpleDB, Google DataStore<br />Document Store - dados já sumarizados, geralmente com suporte a processamento batch<br />mongodb, couchdb, TerraStore<br />Graph DB - dados são agrupados conforme suas ligações<br />Neo4j, InfoGrid, VertexDB, <br />Tipos de NoSQL DB<br />
  16. 16. MemCached<br />usado para cache<br />dados Transientes <br />sem suporte a queries<br />Principais Produtos<br />
  17. 17. Cassandra e Hbase<br />busca por índices pré-compilados<br />consistência e transação por registro<br />batch distribuído<br />índice particionado<br />suporte a datacenters distribuídos geograficamente<br />Principais Produtos<br />
  18. 18. CouchDB e MongoDB<br />batch distribuído<br />queries dinâmicas distribuídas (porém limitadas)<br />suporte ao protocolo REST<br />Principais Produtos<br />
  19. 19. Twitter<br />timeline == consolidação dos tweets<br />tweet imutável. <br />todos os dados do tweet são autocontidos (foto do perfil, @name, etc.)<br />tweets da timeline são transientes <br />1 cópia do tweet é guardado no seu "perfil" e replicado async na timeline dos seus seguidores<br />Descrições de Casos Reais<br />
  20. 20. Facebook<br />cada item do mural possui uma consolidação dos comentários desse item<br />a cada atualização dos comentários de um item, ele é reescrito totalmente<br />Descrições de Casos Reais<br />
  21. 21. Google<br />cópia de cada página web que é indexada<br />emails do gmail<br />anexos do gmail (truque da capacidade do gmail)<br />Descrições de Casos Reais<br />
  22. 22. Twitter, Google, Facebook deixaram de utilizar RDBMS?<br />RDBMS morreu?<br />
  23. 23. Twitter, Google, Facebook deixaram de utilizar RDBMS?<br />NÃO!<br /> Para sistemas internos e coisas mais simples ainda usam muito RDBMS, por causa de:<br />maturidade <br />manipulação de dados <br />expertise<br />RDBMS morreu?<br />
  24. 24. Key/Valeu (Distributed Hash Table) <br />Inside NoSQL<br />D1<br />a<br />b<br />C1<br />c<br />d<br />D2<br />e<br />f<br />C2<br />g<br />h<br />...<br />...<br />Dn<br />Cn<br />M<br />i<br />j<br />k<br />
  25. 25. Key/Valeu (Distributed Hash Table) <br />Inside NoSQL<br />D1<br />a<br />b<br />Qual a quantidade de servidores de dados?<br />C1<br />c<br />d<br />D2<br />e<br />f<br />C2<br />g<br />h<br />...<br />...<br />Dn<br />Cn<br />M<br />i<br />j<br />k<br />
  26. 26. Key/Valeu (Distributed Hash Table) <br />Inside NoSQL<br />D1<br />a<br />b<br />C1<br />c<br />d<br />D2<br />Temos 8 servidores de dados<br />e<br />f<br />C2<br />g<br />h<br />...<br />...<br />Dn<br />Cn<br />M<br />i<br />j<br />k<br />
  27. 27. Key/Valeu (Distributed Hash Table) <br />Inside NoSQL<br />D1<br />Bom, temos 8 servidores e o dado com chave “f” vai estar... (calcula) no servidor D2<br />a<br />b<br />C1<br />c<br />d<br />D2<br />e<br />f<br />C2<br />g<br />h<br />...<br />...<br />Dn<br />Cn<br />M<br />i<br />j<br />k<br />
  28. 28. Key/Valeu (Distributed Hash Table) <br />Inside NoSQL<br />D1<br />a<br />b<br />Quero o dado “f”<br />C1<br />c<br />d<br />D2<br />e<br />f<br />C2<br />g<br />h<br />...<br />...<br />Dn<br />Cn<br />M<br />i<br />j<br />k<br />
  29. 29. Key/Valeu (Distributed Hash Table) <br />Inside NoSQL<br />D1<br />a<br />b<br />c<br />d<br />D2<br />e<br />f<br />C1<br />g<br />h<br />D9<br />C2<br />...<br />Chegou servidor novo!<br />...<br />Dn<br />Cn<br />M<br />i<br />j<br />k<br />
  30. 30. Key/Valeu (Distributed Hash Table) <br />Inside NoSQL<br />D1<br />a<br />b<br />c<br />d<br />D2<br />e<br />f<br />C1<br />g<br />h<br />ReHash com 9 servidores agora!<br />D9<br />C2<br />...<br />...<br />Dn<br />Cn<br />M<br />i<br />j<br />k<br />
  31. 31. Key/Valeu (Distributed Hash Table) <br />Inside NoSQL<br />D1<br />a<br />d<br />z<br />k<br />D2<br />g<br />h<br />C1<br />w<br />q<br />D3<br />C2<br />u<br />f<br />g<br />h<br />...<br />...<br />Dn<br />Cn<br />M<br />
  32. 32. NoSQL Live Boston<br />Google IO<br />NoSQLSummer<br />NosqlDay 2011<br />no:sql(east)<br />no:sql(br).<br />15/05/2010 São Paulo - SP<br />http://nosqlbr.com/<br />Eventos<br />
  33. 33. http://www.25hoursaday.com/weblog/<br />http://highscalability.com/<br />http://www.nosqlbr.com.br/<br />http://escalabilidade.com<br />http://www.slideshare.net/marin_dimitrov/nosql-databases-3584443<br />http://www.sitepen.com/blog/2010/05/11/nosql-architecture/<br />Referências<br />
  34. 34. Obrigado <br />@jornaljava<br />

×