NoSQL (Not Only SQL) Nico Steppat [email_address]
Non-Relational DBMS http://www.slideshare.net/chrisbaglieri/non-relational-databases-2143723
Arquitetura / Tiers
Exemplo Tiers
Escalando o sistema
Escalando o sistema
Escalando Application Tier
Escalando Database Tier
Escalando Database Tier ???
Escalabilidade Horizontal  (Scale Out):  Vertical  (Scale Up):
Escalabilidade – Banco de Dados Relacionais Horizontal  (Scale Out):  Vertical  (Scale Up):
Escalabilidade Vertical - Scale Up <ul>Vantagens: <ul><li>Simples </li></ul>Desvantagens: <ul><li>Caro
Limitado
Lento:  </li><ul><li>„ Disc is the new Tape“
Random-Acces </li></ul></ul></ul>
Escalabilidade Horizontal – Cache
Escalabilidade Horizontal – Replicação <ul><li>Fail-over support
Síncrono, Assícrono
Read-Slave </li></ul>
Escalabilidade Horizontal – Replicação Multi-Slave <ul><li>Master – Escrita
Slaves – Leitura
Escrita?? </li></ul>
Escalabilidade Horizontal – Replicação Multi-Master <ul><li>2-PC?
Escrita? </li></ul>
Escalabilidade Horizontal – Resumo <ul><li>Como lidar o volume de dados?
Como escalar escritas?
TX distribuído não escala! </li></ul>
Escalabilidade Horizontal
Escalabilidade Horizontal – Shared Nothing
Shared Nothing - Sharding Scheme
Shared Nothing – Sharding Scheme
Escalabilidade Horizontal – Shared Nothing <ul><li>Joins?
Normalização?
Integridade?
Chaves Compostas?
Alerações de esquema?
2-PC? </li></ul>
Próximos SlideShares
Carregando em…5
×

NoSQL - Caelum Day 2009

2.272 visualizações

Publicada em

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

Publicada em: Tecnologia
1 comentário
3 gostaram
Estatísticas
Notas
Sem downloads
Visualizações
Visualizações totais
2.272
No SlideShare
0
A partir de incorporações
0
Número de incorporações
10
Ações
Compartilhamentos
0
Downloads
92
Comentários
1
Gostaram
3
Incorporações 0
Nenhuma incorporação

Nenhuma nota no 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.
  • NoSQL - Caelum Day 2009

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

    ×