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 :(

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

11. Escalabilidade
Disponibilidade
Consistência
Performance

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

24. Família de Colunas

25. Família de Super Colunas

26. Família de Super Colunas
keyspace

27. Arquitetura Distribuída

28. Baseada no
Dynamo
* Amazon *

29. Redes P2P

30. Redes P2P
ZA DO
TR ALI
ES CEN
D

31. Gossip / Scuttlebutt

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

34. Distributed Hash Tables

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

36. Consistent Hashing

37. Consistent Hashing

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

48. Escrita e Leitura

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!

57. Deleção distribuída

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

67. Configuração do cluster

68. Configuração do cluster

69. Configuração do cluster

70. Configuração do cluster

71. Configuração do cluster

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