NoSQL - Caelum Day 2009
•Transferir como ODP, PDF•
3 gostaram•1,121 visualizações
O documento discute os desafios e abordagens para escalabilidade horizontal e disponibilidade em bancos de dados não-relacionais. Aborda técnicas como replicação, particionamento e consistência eventual para permitir que sistemas de banco de dados suportem altos volumes de dados e requisições mantendo disponibilidade mesmo quando há falhas. Discutem-se as vantagens e desvantagens de sacrificar propriedades ACID em favor de disponibilidade.
![NoSQL (Not Only SQL) Nico Steppat [email_address]](https://image.slidesharecdn.com/nosql-caelumday-2009-nico-091111064045-phpapp01/85/NoSQL-Caelum-Day-2009-1-320.jpg)
Mais conteúdo relacionado
Semelhante a NoSQL - Caelum Day 2009
Semelhante a NoSQL - Caelum Day 2009 (20)
Último
Último (8)
NoSQL - Caelum Day 2009
- 1. NoSQL (Not Only SQL) Nico Steppat [email_address]
- 9. Escalando Database Tier ???
- 10. Escalabilidade Horizontal (Scale Out): Vertical (Scale Up):
- 11. Escalabilidade – Banco de Dados Relacionais Horizontal (Scale Out): Vertical (Scale Up):
- 13. Limitado
- 15. Random-Acces
- 16. Escalabilidade Horizontal – Cache
- 19. Read-Slave
- 21. Slaves – Leitura
- 22. Escrita??
- 24. Escrita?
- 27. TX distribuído não escala!
- 29. Escalabilidade Horizontal – Shared Nothing
- 30. Shared Nothing - Sharding Scheme
- 31. Shared Nothing – Sharding Scheme
- 33. Normalização?
- 34. Integridade?
- 37. 2-PC?
- 39. Normalização?
- 40. Integridade?
- 43. 2-PC? Not Only SQL SQL
- 45. Normalização Schema-free, Compression
- 46. Integridade Aplicação faz
- 47. Chaves Compostas ID simples
- 48. 2-PC T X Local, DLM, Consensus
- 49. Alerações de esquema? Ao vivo SQL
- 51. Replicação
- 52. Gerenciamento
- 53. Consistência
- 54. Modelo de dados SQL
- 57. Cluster de bancos de dados
- 59. Dr. Eric A. Brewer, 2000, PODC
- 60. Escalabilidade Horizontal – Shared-Disk
- 62. Replicação
- 63. LDAP
- 64. RDBMS qualquer
- 66. ScaleDB (MySQL)
- 71. SimpleDB
- 76. Google File System http://labs.google.com/papers/bigtable.html
- 79. pessimista
- 80. BigTable (DLM) - GAE
- 81. Chubby (Paxos)
- 83. Scalaris (Paxos)
Notas do Editor
- Limitado (espaço + processamento) Criado há 25 anos atrais Fala da escalabilidade horizontal
- Disco gigantesco RAC, ScaleDB, PGCluster II Componentes caros, configuracao nao simples, solucoes caros Muda nada para o DBA, modelo igual. Todas as funcoes continuem igual. É bacana, mas complexo. Cloud??
- * Separando os dados em fatias * Table partitioning ou Functional Sharding * 3 bancos diferentes (recursos, tipos) * dbs menores são mais facil de gerenciar, sao simples e mais rapido - gasto!
- Functional Sharding continuacao 3 Range based sharding ( nome do cliente, data, id) Separando mais ainda Espalhando as escritas mais ainda Separando hot e cold data (vendas) – bom e ruim Joins distribuidos? Normalização (exemplo endereco)?
- Hash based, nao é mais functional Key para algum valor? Qual seria a estrutura desse valor? Escalabilidade linear!!!! Mesma tarefa para todos os shards
- 1) Joins são custosos, aplicacao fez já que cada componente só conhece os seus dados 2) Para evitar os joins podemos denormalizar (endereço). Parece loco 3) Não tem mais como garantir integridade pelo banco, o banco tem apenas fatias. Nao enxerga mais o outro lado. 4) Tem uma separacao funcional, chaves auxiliares faciltam muito o espalhamento. 5) esquema pode ser alterado ao vivo (dependendo do banco isso já é possivel) – mas aqui é mais facil, pq o modelo é mais facil. 6) podemos usar tx distribuido (JTA). nao vai ter tx distribuido (gargalho), desempenho da sua aplicacao é a soma do compenente mais devagar. A) Banco faz primeiramente a persistencia, nao tem mais o poder comun, perdeu varios funcoes comuns B) aplicacao assume mais responsibilidade para cuidar os dados. O banco é ainda relacional?
- O desafio está na distribuicao dos dados, bds tradicionais nao foram concipados para isso. Foram concipados e creseram cuidadando os dados, dando garantias fortes. Aqui os bancos relacionais falham ou precisam de ajuda de um SAN – com tradeoff claro. Banco? É mais um armazenamento de chave-valor, um lugar onde vc associar uma chave como um valor. Modelo: key-blob, sempre suficiente bd foram otimizados para OLAP mas nao par OLTP Como replica os dados? Replication factor.... Como espalhar os dados (evitando quente e hot)? Consistent hashing ..... Como gerenciar o cluster? Passando configuracoes? Escalando o cluster elasticamente.
- ACID é um modelo facil de programar cheio de garantias. É bom para nos programadores e desejavel. Replicação sincrona – consistente forte Replicação – aumenta a diponibilidade Piora com 2-phase-commit que tenta levar os mesmos garantias para o cluster.
- Importante aqui: para o cliente o cluster é uma coisa só, é uma particicao de rede (nao dados) Cluster com os meus shards JBoss – partition cluster
- Network partitions acontecem, e sao mais provaveis quanto maior o seu cluster. Datacenter separados, mas no mesmo datacenter – cabo quebrou, routeador queimou. Lidar com esses tipos de problema se chama „Toleranca referente as particioes na rede“
- Brewer é da universidade Berkeley. „ estou criando com minha empresa um banco distribuitdo, e percibi seguinte ESCOLHE DOIS. acho que isso é um lei. Ou seja nao tem como fugir “ Fez o keynote na conferência „Principles of Distribiuted Computing“. 3 atributos arquiteturais para um sistema que é stateful e distribuido. É lei e já foi comprovado. Fala que essa regra é sobre garantias. É impossível garantir os tres.
- Amazon RDS Fala do backup no S3, fala do downtime, fala do failure rate Nao tem garantia que isso nao acontessse, mas pode diminiur a chance. Administracao, qualidade dos componentes. Pode diminiur a chance que isso acontesse. Gastos!!! mas nao tem garantias. Cluster deve funcionar com hardware comun! Nosso design da banco deve funcionar pra qq tipo de hardware...
- Nossos bancos tradicionais sao fortemente consistente e altamente disponiveis. Outro sistema com os mesmos propridades é um LDAP. Nunca serao partition tolerante.sistema para de funcionar.
- Quanto maior o seu cluster mais provavel de partitions. Caro e complexo de evitar (nao tem garantais). Bancos tradicionais nao foram concipados para isso. Foram concipados para OLAP uns 25 anos atrais. ACID te dar garantias fortes que talvez nao funcionam no seu cluster. Carrinho – stateful Altamente disponivel – availability Cluster enorme – partition tolerante Escreve dois artigos famosos
- Always writable Isso nao é locura e uma consequencia. Nao tem jeito. Dynamo é a base para varios servicos no amazon, s3 de mesmo jeito.