Fulvio Longhi@jornaljavaBanco de Dados NoSQL  Escalabilidade de Dados sem LimitesJornalJava.comFev/2011
InformaçõesConceitoPrincipais CaracterísticasExemplosQuem está Usando?Prós e ContrasCAPTipos de NoSQL DBPrincipais ProdutosCasos ReaisInside NoSQLReferênciasPerguntasAgenda
A cada ano é criado quase 2x mais dados que o ano anterior (IDC 2007)Grandes sites viram que ACID não escala muito bem99% dos casos de gargalo um sistema pelo IO (seja de rede ou de disco)Algumas Informações
E você acha que tem problemas com dados?Twitter ~ 1,2 milhões ops/sec (2010)Facebook ~ 500 milhões writes/day (2008)Google ~ 1 trilhão de páginas indexadas/day (2010)
NoSQL == “SQL” || “Not Only SQL”NoSQL == NoRDBMS também (geralmente)“	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)Conceito
baixa latênciasuporte a falhasescalabilidade horizontal e dinâmicaalta disponibilidadeschemas flexiveissuporte a distribuição geográficaBAIXO CUSTObusca de dados através de heurísticameta-indexgeralmente abrindo mão de:transação, locks, consistência, integridade (tarefas do RDBMS)queries complexasPrincipais Características
Escalabilidade: característica de aumentar sua capacidade para o seu sistema (seja de processamento, armazenamento ou IO)Escalabilidade Horizontal: escalar adicionando máquinas em paralelo (ex.: Cluster) desvantagens: sistemas e arquiteturas mais complexasEscalabilidade Vertical: escalar adicionando novos componentes na máquina (ex.: Aumentar memória) desvantagens: caro, e com limites físicos atingíveisMas o que é Escalabilidade Horizontal?
sistemas com quantidade de dados massivoarquitetura essencialmente distribuída muitos servidores para suportar um sistema prover resultado de queries impossíveis de serem feitas com joins onlinesistema com mudanças constantes no schemaExemplos de Utilização
Quem está Usando?
Prósalta disponibilidadeescalabilidade horizontalbaixo custoexpansão dinâmico schemas flexíveisdados distribuídossemi-estruturadosPrós e Contras
Contrasqueries dinâmicas limitadasconsistência fica por conta do programa sem padrãosem controle de acesso Prós e Contras
Eric Brewer - Berkeley/MIT, 2000Diagrama CAP
Consistence - após a operação, o dado já está pronto pra consultatodos consultam os mesmos dadosAvailability - sempre disponíveltolerante a falhas de máquinas individuaisexpansão sem downtimePartition Tolerance - os dados estão espalhados em várias máquinas (não apenas para leitura, mas para escrita também!)Teorema CAP
CA - RDBMS comuns (as vezes em pequenos Clusters)o único meio de escalar é verticalmenteCP - Shard (Tabelas particionadas)se uma tabela estiver fora do ar, parte dos dados serão afetadosprogramas mais complexos para manter a consistênciaAP - DNS, cache, NoSQLdifícil manter consistência, resolver conflitosCombinações de CAP
Key/Value - no modelo de Distribuited Hash TableMemCached, Amazon S3, Google Storage, Azure DB, Yahoo PnutsColumn Store - pode-se buscar dados por key:columnApache Cassandra, Apache HBase, Amazon SimpleDB, Google DataStoreDocument Store - dados já sumarizados, geralmente com suporte a processamento batchmongodb, couchdb, TerraStoreGraph DB - dados são agrupados conforme suas ligaçõesNeo4j, InfoGrid, VertexDB, Tipos de NoSQL DB
MemCachedusado para cachedados Transientes	sem suporte a queriesPrincipais Produtos
Cassandra e Hbasebusca por índices pré-compiladosconsistência e transação por registrobatch distribuídoíndice particionadosuporte a datacenters distribuídos geograficamentePrincipais Produtos
CouchDB e MongoDBbatch distribuídoqueries dinâmicas distribuídas (porém limitadas)suporte ao protocolo RESTPrincipais Produtos
Twittertimeline == consolidação dos tweetstweet imutável. todos os dados do tweet são autocontidos (foto do perfil, @name, etc.)tweets da timeline são transientes 1 cópia do tweet é guardado no seu "perfil" e replicado async na timeline dos seus seguidoresDescrições de Casos Reais
Facebookcada item do mural possui uma consolidação dos comentários desse itema cada atualização dos comentários de um item, ele é reescrito totalmenteDescrições de Casos Reais
Googlecópia de cada página web que é indexadaemails do gmailanexos do gmail (truque da capacidade do gmail)Descrições de Casos Reais
Twitter, Google, Facebook deixaram de utilizar RDBMS?RDBMS morreu?
Twitter, Google, Facebook deixaram de utilizar RDBMS?NÃO!	Para sistemas internos e coisas mais simples ainda usam muito RDBMS, por causa de:maturidade  manipulação de dados expertiseRDBMS morreu?
Key/Valeu (Distributed Hash Table) Inside NoSQLD1abC1cdD2efC2gh......DnCnMijk
Key/Valeu (Distributed Hash Table) Inside NoSQLD1abQual a quantidade de servidores de dados?C1cdD2efC2gh......DnCnMijk
Key/Valeu (Distributed Hash Table) Inside NoSQLD1abC1cdD2Temos 8 servidores de dadosefC2gh......DnCnMijk
Key/Valeu (Distributed Hash Table) Inside NoSQLD1Bom, temos 8 servidores e o dado com chave “f” vai estar... (calcula) no  servidor D2abC1cdD2efC2gh......DnCnMijk
Key/Valeu (Distributed Hash Table) Inside NoSQLD1abQuero o dado “f”C1cdD2efC2gh......DnCnMijk
Key/Valeu (Distributed Hash Table) Inside NoSQLD1abcdD2efC1ghD9C2...Chegou servidor novo!...DnCnMijk
Key/Valeu (Distributed Hash Table) Inside NoSQLD1abcdD2efC1ghReHash com 9 servidores agora!D9C2......DnCnMijk
Key/Valeu (Distributed Hash Table) Inside NoSQLD1adzkD2ghC1wqD3C2ufgh......DnCnM
NoSQL Live BostonGoogle IONoSQLSummerNosqlDay 2011no:sql(east)no:sql(br).15/05/2010 São Paulo - SPhttp://nosqlbr.com/Eventos
http://www.25hoursaday.com/weblog/http://highscalability.com/http://www.nosqlbr.com.br/http://escalabilidade.comhttp://www.slideshare.net/marin_dimitrov/nosql-databases-3584443http://www.sitepen.com/blog/2010/05/11/nosql-architecture/Referências
Obrigado @jornaljava

Banco de Dados NoSql - JornalJava

  • 1.
    Fulvio Longhi@jornaljavaBanco deDados NoSQL Escalabilidade de Dados sem LimitesJornalJava.comFev/2011
  • 2.
    InformaçõesConceitoPrincipais CaracterísticasExemplosQuem estáUsando?Prós e ContrasCAPTipos de NoSQL DBPrincipais ProdutosCasos ReaisInside NoSQLReferênciasPerguntasAgenda
  • 3.
    A cada anoé criado quase 2x mais dados que o ano anterior (IDC 2007)Grandes sites viram que ACID não escala muito bem99% dos casos de gargalo um sistema pelo IO (seja de rede ou de disco)Algumas Informações
  • 4.
    E você achaque tem problemas com dados?Twitter ~ 1,2 milhões ops/sec (2010)Facebook ~ 500 milhões writes/day (2008)Google ~ 1 trilhão de páginas indexadas/day (2010)
  • 5.
    NoSQL == “SQL”|| “Not Only SQL”NoSQL == NoRDBMS também (geralmente)“ 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)Conceito
  • 6.
    baixa latênciasuporte afalhasescalabilidade horizontal e dinâmicaalta disponibilidadeschemas flexiveissuporte a distribuição geográficaBAIXO CUSTObusca de dados através de heurísticameta-indexgeralmente abrindo mão de:transação, locks, consistência, integridade (tarefas do RDBMS)queries complexasPrincipais Características
  • 7.
    Escalabilidade: característica deaumentar sua capacidade para o seu sistema (seja de processamento, armazenamento ou IO)Escalabilidade Horizontal: escalar adicionando máquinas em paralelo (ex.: Cluster) desvantagens: sistemas e arquiteturas mais complexasEscalabilidade Vertical: escalar adicionando novos componentes na máquina (ex.: Aumentar memória) desvantagens: caro, e com limites físicos atingíveisMas o que é Escalabilidade Horizontal?
  • 8.
    sistemas com quantidadede dados massivoarquitetura essencialmente distribuída muitos servidores para suportar um sistema prover resultado de queries impossíveis de serem feitas com joins onlinesistema com mudanças constantes no schemaExemplos de Utilização
  • 9.
  • 10.
    Prósalta disponibilidadeescalabilidade horizontalbaixocustoexpansão dinâmico schemas flexíveisdados distribuídossemi-estruturadosPrós e Contras
  • 11.
    Contrasqueries dinâmicas limitadasconsistênciafica por conta do programa sem padrãosem controle de acesso Prós e Contras
  • 12.
    Eric Brewer -Berkeley/MIT, 2000Diagrama CAP
  • 13.
    Consistence - apósa operação, o dado já está pronto pra consultatodos consultam os mesmos dadosAvailability - sempre disponíveltolerante a falhas de máquinas individuaisexpansão sem downtimePartition Tolerance - os dados estão espalhados em várias máquinas (não apenas para leitura, mas para escrita também!)Teorema CAP
  • 14.
    CA - RDBMScomuns (as vezes em pequenos Clusters)o único meio de escalar é verticalmenteCP - Shard (Tabelas particionadas)se uma tabela estiver fora do ar, parte dos dados serão afetadosprogramas mais complexos para manter a consistênciaAP - DNS, cache, NoSQLdifícil manter consistência, resolver conflitosCombinações de CAP
  • 15.
    Key/Value - nomodelo de Distribuited Hash TableMemCached, Amazon S3, Google Storage, Azure DB, Yahoo PnutsColumn Store - pode-se buscar dados por key:columnApache Cassandra, Apache HBase, Amazon SimpleDB, Google DataStoreDocument Store - dados já sumarizados, geralmente com suporte a processamento batchmongodb, couchdb, TerraStoreGraph DB - dados são agrupados conforme suas ligaçõesNeo4j, InfoGrid, VertexDB, Tipos de NoSQL DB
  • 16.
    MemCachedusado para cachedadosTransientes sem suporte a queriesPrincipais Produtos
  • 17.
    Cassandra e Hbasebuscapor índices pré-compiladosconsistência e transação por registrobatch distribuídoíndice particionadosuporte a datacenters distribuídos geograficamentePrincipais Produtos
  • 18.
    CouchDB e MongoDBbatchdistribuídoqueries dinâmicas distribuídas (porém limitadas)suporte ao protocolo RESTPrincipais Produtos
  • 19.
    Twittertimeline == consolidaçãodos tweetstweet imutável. todos os dados do tweet são autocontidos (foto do perfil, @name, etc.)tweets da timeline são transientes 1 cópia do tweet é guardado no seu "perfil" e replicado async na timeline dos seus seguidoresDescrições de Casos Reais
  • 20.
    Facebookcada item domural possui uma consolidação dos comentários desse itema cada atualização dos comentários de um item, ele é reescrito totalmenteDescrições de Casos Reais
  • 21.
    Googlecópia de cadapágina web que é indexadaemails do gmailanexos do gmail (truque da capacidade do gmail)Descrições de Casos Reais
  • 22.
    Twitter, Google, Facebookdeixaram de utilizar RDBMS?RDBMS morreu?
  • 23.
    Twitter, Google, Facebookdeixaram de utilizar RDBMS?NÃO! Para sistemas internos e coisas mais simples ainda usam muito RDBMS, por causa de:maturidade manipulação de dados expertiseRDBMS morreu?
  • 24.
    Key/Valeu (Distributed HashTable) Inside NoSQLD1abC1cdD2efC2gh......DnCnMijk
  • 25.
    Key/Valeu (Distributed HashTable) Inside NoSQLD1abQual a quantidade de servidores de dados?C1cdD2efC2gh......DnCnMijk
  • 26.
    Key/Valeu (Distributed HashTable) Inside NoSQLD1abC1cdD2Temos 8 servidores de dadosefC2gh......DnCnMijk
  • 27.
    Key/Valeu (Distributed HashTable) Inside NoSQLD1Bom, temos 8 servidores e o dado com chave “f” vai estar... (calcula) no servidor D2abC1cdD2efC2gh......DnCnMijk
  • 28.
    Key/Valeu (Distributed HashTable) Inside NoSQLD1abQuero o dado “f”C1cdD2efC2gh......DnCnMijk
  • 29.
    Key/Valeu (Distributed HashTable) Inside NoSQLD1abcdD2efC1ghD9C2...Chegou servidor novo!...DnCnMijk
  • 30.
    Key/Valeu (Distributed HashTable) Inside NoSQLD1abcdD2efC1ghReHash com 9 servidores agora!D9C2......DnCnMijk
  • 31.
    Key/Valeu (Distributed HashTable) Inside NoSQLD1adzkD2ghC1wqD3C2ufgh......DnCnM
  • 32.
    NoSQL Live BostonGoogleIONoSQLSummerNosqlDay 2011no:sql(east)no:sql(br).15/05/2010 São Paulo - SPhttp://nosqlbr.com/Eventos
  • 33.
  • 34.