Distribuição de Dados em Escala Global com Cassandra
1 gostou758 visualizações
O documento discute a distribuição de dados em escala global utilizando o Cassandra, abordando sua arquitetura distribuída e modelo de dados. O Cassandra oferece uma configuração flexível entre escalabilidade, disponibilidade e consistência, sendo adequado para o ambiente de Big Data da Web 2.0. Além disso, apresenta um estudo de caso que demonstra a eficácia do Cassandra em situações de leitura e escrita em um cluster simples.
Distribuição de Dados em Escala Global com Cassandra
- 1. Distribuição de dados em escala global com Cassandra Mário Sérgio Coelho Marroquim mariomarroquim@gmail.com http://blogdomariomarroquim.wordpress.com
- 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. Web 2.0 :)
- 4. Big Data
- 5. Facebook: 845 mi de usuários Twitter: 140 mi de tweets por dia LE MA PR OB
- 6. Múltiplos servidores! UÇÃO SOL
- 7. Múltiplos data centers! UÇÃO SOL
- 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. A rede VAI falhar
- 10. Os nós VÃO falhar
- 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. 2-phase commit COORDENADOR SERVIDORES
- 15. Banco NoSQL Feito em Java Criado em 2008
- 16. ACID LE MA PR OB
- 17. CAP Consistência | Disponibilidade | Tolerância UÇÃO SO L
- 19. 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
- 20. Modelo de dados
- 21. BigTable ● Criado pelo Google em 2004 ● Sem tabelas ou relacionamentos ● É fácil de particionar e replicar ● Altamente escalável ● Baseado em colunas
- 22. Coluna
- 23. Super Coluna
- 25. Família de Super Colunas
- 26. Família de Super Colunas keyspace
- 28. Baseada no Dynamo * Amazon *
- 29. Redes P2P
- 30. Redes P2P ZA DO TR ALI ES CEN D
- 32. 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
- 33. Gossip / Scuttlebutt EN TE TELIG IN
- 35. 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
- 38. 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
- 39. Particionamento
- 40. Particionamento AB E! ÁS ÊJ V OC
- 41. Replicação
- 42. 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
- 43. Replicação
- 44. Simple Strategy Desconsidera hacks e datacenters Considera apenas a distribuição circular dos nós no data center!
- 45. Old Network Topology Strategy Considera os hacks em um mesmo data center Uma das réplicas é enviada para outro data center!
- 46. Network Topology Strategy Considera os hacks em todos os data center Permite parametrização de detalhes para otimização da rep.
- 47. 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
- 49. 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
- 50. Escrita e Leitura R Número mínimo de nós que devem responder de forma síncrona à uma operação de LEITURA
- 51. Escrita e Leitura W Número mínimo de nós que devem responder de forma síncrona à uma operação de ESCRITA
- 52. Escrita e Leitura R+W>N Maior consistência
- 53. Escrita e Leitura W=1 Escritas nunca irão falhar
- 54. Escrita e Leitura R e W altos Maior consistência, menor performance
- 55. Escrita e Leitura N alto Maior durabilidade, boa performance
- 56. 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!
- 58. 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
- 59. Detecção e correção de conflitos / falhas
- 60. Hinted Handoff ● Um nó substitui outro nó indisponível ● Temporário, sincronização posterior ● Baseado no protocolo Gossip ● Rápido, assíncrono
- 61. Read Repair ● Sincronização de dados sob demanda ● Uso do campo timestamp ● Rápido, assíncrono
- 62. 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!
- 63. Protocolo anti-entropia Nó #1, Chave 13 Nó #2, Chave 13
- 64. Estudo de caso
- 65. Projeto Cassandra Hits ● Cluster simples, 2 servidores ● Centenas de escritas e leituras ● Escalabilidade x Performance https://github.com/mariomarroquim/cassandra-hits
- 66. 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
- 72. Resultados obtidos Os 2 nós respondem normalmente às requisições
- 73. Resultados obtidos Após a queda do segundo nó, a velocidade diminui
- 74. Resultados obtidos Após a volta do segundo nó, a velocidade inicial é retomada
- 75. Conclusões
- 76. 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!
- 77. Dúvidas?
- 78. Distribuição de dados em escala global com Cassandra Mário Sérgio Coelho Marroquim mariomarroquim@gmail.com http://blogdomariomarroquim.wordpress.com