Embed Size (px)
DESCRIPTION
Apresentação do artigo para conclusão da minha Especialização em Banco de Dados, no IFPI, em 2012
Citation preview
Distribuição de dados em escala global com
CassandraMário Sérgio Coelho Marroquim
[email protected]://blogdomariomarroquim.wordpress.com
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
Web 2.0 :)Web 2.0 :)
Big Data
Facebook: 845 mi de usuários
Twitter: 140 mi de tweets por dia
PROBLEMA
Múltiplos servidores!
SOLUÇÃO
Múltiplos data centers!
SOLUÇÃO
Dist. de dados em escala global!
● Baixa latência da rede
● Melhor balanceamento de carga
● Alta disponibilidade do serviço
● Maior performance geral
● (...)
A rede VAI falhar
Os nós VÃO falhar
EscalabilidadeDisponibilidade
ConsistênciaPerformance
Bases de dados relacionais
● Propriedades ACID- Atomicidade- Consistência- Isolamento- Durabilidade
● Normalizações● 2-phase commit / 2-phase locking
- Baixa performance- Deadlocks
PROBLEMA
2-phase commit
SERVIDORES
COORDENADOR
Banco NoSQLFeito em Java
Criado em 2008
ACIDPROBLEMA
CAPConsistência | Disponibilidade | Tolerância
SOLUÇÃO
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
Modelo de dados
BigTable
● Criado pelo Google em 2004
● Sem tabelas ou relacionamentos
● É fácil de particionar e replicar
● Altamente escalável
● Baseado em colunas
Coluna
Super Coluna
Família de Colunas
Família de Super Colunas
Família de Super Colunas
keys
pace
Arquitetura Distribuída
Baseada noDynamo
* Amazon *
Redes P2P
Redes P2P
DESCENTRALIZADO
Gossip / Scuttlebutt
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
Gossip / Scuttlebutt
INTELIGENTE
Distributed Hash Tables
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
Consistent Hashing
Consistent Hashing
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
Particionamento
VOCÊ JÁ SABE!
Particionamento
Replicação
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
Replicação
Simple StrategyDesconsidera hacks e datacenters
Considera apenas a distribuição circular dos nós no data center!
Old Network Topology StrategyConsidera os hacks em um mesmo data center
Uma das réplicas é enviada para outro data center!
Network Topology StrategyConsidera os hacks em todos os data center
Permite parametrização de detalhes para otimização da rep.
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
Escrita e Leitura
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
RNúmero mínimo de nós que devem responder
de forma síncrona à uma operação de LEITURA
Escrita e Leitura
WNúmero mínimo de nós que devem responder de
forma síncrona à uma operação de ESCRITA
Escrita e Leitura
R + W > NMaior consistência
Escrita e Leitura
W = 1Escritas nunca irão falhar
Escrita e Leitura
R e W altosMaior consistência, menor performance
Escrita e Leitura
N altoMaior durabilidade, boa performance
Escrita e Leitura
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!
Deleção distribuída
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
Detecção e correção de conflitos / falhas
Hinted Handoff
● Um nó substitui outro nó indisponível
● Temporário, sincronização posterior
● Baseado no protocolo Gossip
● Rápido, assíncrono
Read Repair
● Sincronização de dados sob demanda
● Uso do campo timestamp
● Rápido, assíncrono
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!
Protocolo anti-entropia
Nó #1, Chave 13 Nó #2, Chave 13
Estudo de caso
Projeto Cassandra Hits
● Cluster simples, 2 servidores
● Centenas de escritas e leituras
● Escalabilidade x Performance
https://github.com/mariomarroquim/cassandra-hits
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
Configuração do cluster
Configuração do cluster
Configuração do cluster
Configuração do cluster
Configuração do cluster
Resultados obtidos
Os 2 nós respondem normalmente às requisições
Resultados obtidos
Após a queda do segundo nó, a velocidade diminui
Resultados obtidos
Após a volta do segundo nó, a velocidade inicial é retomada
Conclusões
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!
Dúvidas?
Distribuição de dados em escala global com
CassandraMário Sérgio Coelho Marroquim
[email protected]://blogdomariomarroquim.wordpress.com
