Distribuição de dados em escala global com

CassandraMário Sérgio Coelho Marroquim

mariomarroquim@gmail.comhttp://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

mariomarroquim@gmail.comhttp://blogdomariomarroquim.wordpress.com