Your SlideShare is downloading. ×
0
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
NoSQL - Caelum Day 2009
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

NoSQL - Caelum Day 2009

1,775

Published on

short apresentation (in portuguese) about database scalability and the cap theorem

short apresentation (in portuguese) about database scalability and the cap theorem

Published in: Technology
1 Comment
3 Likes
Statistics
Notes
No Downloads
Views
Total Views
1,775
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
86
Comments
1
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 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.
  • Transcript

    • 1. NoSQL (Not Only SQL) Nico Steppat [email_address]
    • 2. Non-Relational DBMS http://www.slideshare.net/chrisbaglieri/non-relational-databases-2143723
    • 3. Arquitetura / Tiers
    • 4. Exemplo Tiers
    • 5. Escalando o sistema
    • 6. Escalando o sistema
    • 7. Escalando Application Tier
    • 8. Escalando Database Tier
    • 9. Escalando Database Tier ???
    • 10. Escalabilidade Horizontal (Scale Out): Vertical (Scale Up):
    • 11. Escalabilidade – Banco de Dados Relacionais Horizontal (Scale Out): Vertical (Scale Up):
    • 12. Escalabilidade Vertical - Scale Up <ul>Vantagens: <ul><li>Simples </li></ul>Desvantagens: <ul><li>Caro
    • 13. Limitado
    • 14. Lento: </li><ul><li>„ Disc is the new Tape“
    • 15. Random-Acces </li></ul></ul></ul>
    • 16. Escalabilidade Horizontal – Cache
    • 17. Escalabilidade Horizontal – Replicação <ul><li>Fail-over support
    • 18. Síncrono, Assícrono
    • 19. Read-Slave </li></ul>
    • 20. Escalabilidade Horizontal – Replicação Multi-Slave <ul><li>Master – Escrita
    • 21. Slaves – Leitura
    • 22. Escrita?? </li></ul>
    • 23. Escalabilidade Horizontal – Replicação Multi-Master <ul><li>2-PC?
    • 24. Escrita? </li></ul>
    • 25. Escalabilidade Horizontal – Resumo <ul><li>Como lidar o volume de dados?
    • 26. Como escalar escritas?
    • 27. TX distribuído não escala! </li></ul>
    • 28. Escalabilidade Horizontal
    • 29. Escalabilidade Horizontal – Shared Nothing
    • 30. Shared Nothing - Sharding Scheme
    • 31. Shared Nothing – Sharding Scheme
    • 32. Escalabilidade Horizontal – Shared Nothing <ul><li>Joins?
    • 33. Normalização?
    • 34. Integridade?
    • 35. Chaves Compostas?
    • 36. Alerações de esquema?
    • 37. 2-PC? </li></ul>
    • 38. Escalabilidade Horizontal – Shared Nothing <ul><li>Joins?
    • 39. Normalização?
    • 40. Integridade?
    • 41. Chaves Compostas?
    • 42. Alerações de esquema?
    • 43. 2-PC? </li></ul>Not Only SQL SQL
    • 44. Escalabilidade Horizontal – Shared Nothing <ul><li>Joins Key, Rango, Indices, Views, Lucene
    • 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 </li></ul>SQL
    • 50. Quais são os desafios? <ul><li>Sharding
    • 51. Replicação
    • 52. Gerenciamento
    • 53. Consistência
    • 54. Modelo de dados </li></ul>SQL
    • 55. Consistência e Disponibilidade <ul>Consistência forte : <ul><li>Transação: A C ID
    • 56. 2-Phase-Commit </li></ul>Alta Disponibilidade: <ul><li>Replicação / Espalhamento </li></ul></ul>
    • 57. Cluster de bancos de dados
    • 58. Partitição da Rede
    • 59. Dr. Eric A. Brewer, 2000, PODC
    • 60. Escalabilidade Horizontal – Shared-Disk
    • 61. Sacrificando Partition Tolerance <ul><li>ACID, 2-Phase-Commit
    • 62. Replicação
    • 63. LDAP
    • 64. RDBMS qualquer
    • 65. „ SAN“s </li><ul><li>Oracle RAC
    • 66. ScaleDB (MySQL)
    • 67. Amazon RDS (MySQL) </li></ul></ul>
    • 68. Consistência? <ul>Como criar um carrinho de compras <ul>altamente disponível (24/7) <ul>em um cluster enorme ? </ul></ul></ul>Werner Vogel, CTO Amazon <ul>Criando um banco parecido com DNS e Bittorrent. Amazon Dynamo . </ul>http://www.allthingsdistributed.com/2008/12/eventually_consistent.html http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html
    • 69. <ul>Sacrificando Consistência (um pouco) </ul><ul><li>Eventualmente Consistente
    • 70. Otimista </li><ul><li>Read-Repair (Quorum) </li></ul><li>Amazon: </li><ul><li>Dynamo
    • 71. SimpleDB
    • 72. S3 (ex: Dropbox) </li></ul><li>Cassandra
    • 73. Project-Voldemort </li></ul>
    • 74. Sacrificando Consistência Disponibilidade (um pouco) <ul><li>BigTable (Google)
    • 75. Baseado em </li><ul><li>Chubby
    • 76. Google File System </li></ul></ul>http://labs.google.com/papers/bigtable.html
    • 77. Sacrificando Disponibilidade (um pouco) <ul><li>Distributed Lock Manager
    • 78. Consensos / Paxos
    • 79. pessimista
    • 80. BigTable (DLM) - GAE
    • 81. Chubby (Paxos)
    • 82. Zookeeper (Paxos)
    • 83. Scalaris (Paxos)
    • 84. BigTable Clones: </li><ul><li>Hbase, HyperTable </li></ul></ul>
    • 85. ACID vs BASE <ul>ACID <ul>A tomicity C onsistency I solation D urability </ul></ul>Contínuo ACID BASE <ul>BASE <ul>B asically A vailable S oft state E ventual Consistency </ul></ul>
    • 86. Obrigado! [email_address]

    ×