Distribuição de Dados em Escala Global com Cassandra

809 views
746 views

Published on

Apresentação do artigo para conclusão da minha Especialização em Banco de Dados, no IFPI, em 2012. NOTA: alguns emails e links podem não mais existir :(

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
809
On SlideShare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
22
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Distribuição de Dados em Escala Global com Cassandra

  1. 1. Distribuição de dados em escala global com Cassandra Mário Sérgio Coelho Marroquim mariomarroquim@gmail.com http://blogdomariomarroquim.wordpress.com
  2. 2. Sumário● A Web 2.0, o Big Data e as bases relacionais● O Casssandra● Modelo de dados, BigTable● Arquitetura distribuída, Dynamo - Redes P2P, Gossip / Scuttlebut - Distributed Hash Tables, hash consistente - Distribuição, escrita, leitura e deleção de dados - Detecção e correção de conflitos / falhas● Estudo de caso● Conclusões
  3. 3. Web 2.0 :)
  4. 4. Big Data
  5. 5. Facebook: 845 mi de usuários  Twitter: 140 mi de tweets por dia LE MA PR OB
  6. 6. Múltiplosservidores! UÇÃO SOL
  7. 7. Múltiplosdata centers! UÇÃO SOL
  8. 8. Dist. de dados em escala global!● Baixa latência da rede● Melhor balanceamento de carga● Alta disponibilidade do serviço● Maior performance geral● (...)
  9. 9. A rede VAI falhar
  10. 10. Os nós VÃO falhar
  11. 11. EscalabilidadeDisponibilidade Consistência Performance
  12. 12. Bases de dados relacionais● Propriedades ACID - Atomicidade - Consistência - Isolamento - Durabilidade● Normalizações● 2-phase commit / 2-phase locking - Baixa performance - Deadlocks LE MA PR OB
  13. 13. 2-phase commit COORDENADOR SERVIDORES
  14. 14. Banco NoSQL Feito em JavaCriado em 2008
  15. 15. ACID LE MA PR OB
  16. 16. CAPConsistência | Disponibilidade | Tolerância UÇÃO SO L
  17. 17. Cassandra● Permite configuração do balanço entre - Escalabilidade - Disponibilidade - Consistência / Durabilidade - Performance - Tolerância a falhas na rede● Sem nó coordenador - Sem SPOF: Single Point Of Failure● Baixo custo, servidores convencionais
  18. 18. Modelo de dados
  19. 19. BigTable● Criado pelo Google em 2004● Sem tabelas ou relacionamentos● É fácil de particionar e replicar● Altamente escalável● Baseado em colunas
  20. 20. Coluna
  21. 21. Super Coluna
  22. 22. Família de Colunas
  23. 23. Família de Super Colunas
  24. 24. Família de Super Colunas keyspace
  25. 25. Arquitetura Distribuída
  26. 26. Baseada no Dynamo * Amazon *
  27. 27. Redes P2P
  28. 28. Redes P2P ZA DO TR ALI ES CEN D
  29. 29. Gossip / Scuttlebutt
  30. 30. Gossip / Scuttlebutt● Cada nó conheçe ao menos outro nó● Propagação epidêmica● Remove a necessidade de um registro centralizado de nós● Scuttlebutt, menor uso de recursos - Accrural Failure Detector
  31. 31. Gossip / Scuttlebutt EN TE TELIG IN
  32. 32. Distributed Hash Tables
  33. 33. Distributed Hash Table● Consistent Hashing - Cada nó é identificado por uma chave - Estrutura circular de nós - Cada linha possui uma chave - Cada linha é alocada no próximo nó com chave maior que a sua
  34. 34. Consistent Hashing
  35. 35. Consistent Hashing
  36. 36. Consistent Hashing● Provoca o particionamento das linhas● Permite prever em qual nó está uma linha● A remoção ou inclusão de nós afeta apenas os seus nós vizinhos
  37. 37. Particionamento
  38. 38. Particionamento AB E! ÁS ÊJ V OC
  39. 39. Replicação
  40. 40. Replicação● Evita um ponto único de falha● Dados são replicados em N - 1 nós - N = fator de replicação● Estratégias específicas para - Apenas um hack - Todo um data center - Todo o cluster● Assíncrona
  41. 41. Replicação
  42. 42. Simple StrategyDesconsidera hacks e datacenters Considera apenas a distribuição circular dos nós no data center!
  43. 43. Old Network Topology StrategyConsidera os hacks em um mesmo data center Uma das réplicas é enviada para outro data center!
  44. 44. Network Topology StrategyConsidera os hacks em todos os data center Permite parametrização de detalhes para otimização da rep.
  45. 45. Replicação● Nenhum nó será responsável por mais de N - 1 nós (Zookeeper)● Aumenta a disponibilidade dos dados● Aumenta a tolerância contra falhas● Não prejudica a performance geral
  46. 46. Escrita e Leitura
  47. 47. Escrita e Leitura● A partir de qualquer nó: descentralização● Redirecionamento para o nó coordenador - Protocolo Gossip, Consistent Hashing● Balanço entre consistência e performance - Configurável - Consistência eventual
  48. 48. Escrita e Leitura R Número mínimo de nós que devem responderde forma síncrona à uma operação de LEITURA
  49. 49. Escrita e Leitura WNúmero mínimo de nós que devem responder de forma síncrona à uma operação de ESCRITA
  50. 50. Escrita e Leitura R+W>N Maior consistência
  51. 51. Escrita e Leitura W=1 Escritas nunca irão falhar
  52. 52. Escrita e Leitura R e W altos Maior consistência, menor performance
  53. 53. Escrita e Leitura N alto Maior durabilidade, boa performance
  54. 54. Quorum, Local Quorum, Each Quorum● Configuração por operação (leit. e escrita)● Ao menos N / 2 + 1 réplicas síncronas● Consideram hacks no mesmo data center e em outros data centers!
  55. 55. Deleção distribuída
  56. 56. Deleção distribuída● Impossibilidade de propagar deleções● Adição (e propagação) de uma coluna chamada tombstone● Limpeza local em cada nó com o comando nodetool repair
  57. 57. Detecção e correção de conflitos / falhas
  58. 58. Hinted Handoff● Um nó substitui outro nó indisponível● Temporário, sincronização posterior● Baseado no protocolo Gossip● Rápido, assíncrono
  59. 59. Read Repair● Sincronização de dados sob demanda● Uso do campo timestamp● Rápido, assíncrono
  60. 60. Protocolo anti-entropia● Baseado em Merkle Trees● MD5 para cada chave, coluna e família● Sincronização baseada em timestamp● Lento, muito uso de CPU e disco● Uso do comando nodetool repair● Corrige o que o Read Repair não corrigiu!
  61. 61. Protocolo anti-entropia Nó #1, Chave 13 Nó #2, Chave 13
  62. 62. Estudo de caso
  63. 63. Projeto Cassandra Hits● Cluster simples, 2 servidores● Centenas de escritas e leituras● Escalabilidade x Performance https://github.com/mariomarroquim/cassandra-hits
  64. 64. Ambiente de teste● Processadores Intel Xeon 2Ghz, quadcore● 2Gb de RAM em um servidor e 512Mb de RAM no outro● Ubuntu Server 10.04 e 10.10 instalados em cada servidor, respectivamente● Java 1.6.31 instalado em ambos
  65. 65. Configuração do cluster
  66. 66. Configuração do cluster
  67. 67. Configuração do cluster
  68. 68. Configuração do cluster
  69. 69. Configuração do cluster
  70. 70. Resultados obtidos Os 2 nós respondem normalmente às requisições
  71. 71. Resultados obtidos Após a queda do segundo nó, a velocidade diminui
  72. 72. Resultados obtidos Após a volta do segundo nó, a velocidade inicial é retomada
  73. 73. Conclusões
  74. 74. Conclusões● O Cassandra está preparado para os desafios da Web 2.0 e do fenômeno do Big Data● Balanço configurável entre escalabilidade, disponibilidade, consistência e performance● Escalabilidade incremental e linear● Provado pelo mercado!
  75. 75. Dúvidas?
  76. 76. Distribuição de dados em escala global com Cassandra Mário Sérgio Coelho Marroquim mariomarroquim@gmail.com http://blogdomariomarroquim.wordpress.com

×