Professional Documents
Culture Documents
Cassandra
l Eugênia Andreis Fernandes
Rafael Ferreira Costa
introdução
● criado originalmente pelo Facebook;
● arquitetura inspirada pelo DynamoDB;
● modelo de dados baseado no BigTable do Google;
● atualmente mantido pela fundação Apache.
2
sobre
● free;
● open source;
● banco de dados não relacional e colunar;
● AP (Availability/Partition tolerance) no teorema de CAP.
3
teorema de CAP
● formulado inicialmente por Eric Brewer em 2000, na
Universidade de Califórnia;
● um sistema de dados compartilhado contém duas dessas
propriedades;
4
teorema de CAP
● Consistency: todos os nós veem o mesmo dado ao mesmo
tempo.
● Availability: disponibilidade do banco para persistência e
leitura.
● Partition Tolerance: o banco deve lidar com falhas de rede,
resolvendo conflitos de forma transparente para os clients.
5
teorema de CAP
Availability
Ca
ss
an
d ra
Consistency Partition tolerance
6
bd colunar
diferente dos bancos relacionais, em que os dados eram
armazenados em linhas (rows), nos bancos colunares os dados
são armazenados em colunas.
8
bd distribuído
1
Anel do
Cassandra
(3 nós)
3 2
9
bd distribuído
● todos os dados são distribuídos uniformemente no anel do Cassandra, de
acordo com um algoritmo hash para criar o número de cópias necessárias,
também chamado de réplicas;
● todas as informações sobre os dados do cluster são trocadas entre os nós
por meio do protocolo gossip;
● essas informações são importante para avisar as conexões do client sobre
qual nó é o melhor para gravar ou ler qualquer dado em um determinado
momento.
10
bd distribuído
coordinator
1
8 2
A r1
A
7 A A 3
r2
Client
6 4
5 11
r3
arquitetura
é segmentado em keyspaces, column families (tables), rows e
columns.
keyspace
column family (table)
row
column
12
keyspace
é o equivalente a um banco de dados no mundo relacional e agrupa as
tabelas do sistema. principais configurações:
● replication factor: define quantas "cópias" existirão dos dados. importante
para alta disponibilidade do banco;
● replica placement strategy: estratégias de replicação dos dados, sendo 2:
○ simpleStrategy: o dado é replicado para o próximo nó (node) do cluster;
○ networkTopologyStrategy: os dados serão persistidos em mais de um
datacenter (o cluster deve estar configurado para ser multi-datacenter).
13
column family (table)
é o equivalente à uma tabela no mundo relacional. possui os atributos:
● primary key: composta de 2 partes:
○ partition key: define qual partição será armazenado o dado;
○ clustering key: restante da chave, esse campo não entra na definição das partições.
● columns: representa as demais colunas da tabela;
● comments: permite comentários para documentação da tabela;
● default_time_to_live: tempo de expiração do registro;
● compression: determina qual algoritmo de compressão o Cassandra utilizará para
essa determinada tabela. default: LZ4Compressor.
14
row
são compostas pela primary key e um conjunto de columns. o Cassandra persiste
apenas os campos que contém valores, diferente de bancos relacionais onde são
alocados recursos para campos nulos, o que significa que as rows podem conter colunas
diferentes.
ROW 1
ROW 2
ROW 3 15
column
composta por 3 campos:
● column key: nome da coluna;
● column value: valor que está sendo persistido;
● timestamp: o Cassandra utiliza esse campo para resolver
conflitos e determinar qual é o valor mais atual.
16
modelagem
● os dados são organizados por partições com uma chave primária
(chave de linha), que fornece acesso a todas as colunas ou
conjunto de pares chave-valor.
17
modelagem
● a chave primária no Cassandra pode conter duas chaves: a
partition key e a clustering key;
● o propósito da partition key é espalhar os dados uniformemente
no cluster;
● a tarefa da clustering key é armazenar em cluster e organizar os
dados de uma partição para permitir consultas eficientes.
18
vantagens
● alta disponibilidade;
● performance;
● extremamente tolerante a falhas;
● escalabilidade linear;
● altamente distribuido;
● suporta N datacenters nativamente.
19
quando não usar
● precisar muita consistência;
● se o volume de dados da aplicação for muito pequena;
● é necessário analisar se o modelo da aplicação suporta
o paradigma colunar.
20
quem está usando?
● Apple: 75.000+ nós, 10 PB de dados;
● Netflix: 2.500 nós, 420 TB de dados e acima de 1 trilhão de
requisições por dia;
● Easou (Google chinês): 270 nós, 300 TB de dados e acima de
800 milhões de requisições por dia;
● eBay: 100+ nós, 250 TB de dados.
21