Sistemas Distribuídos

Gustavo Henrique GonçalvesMateus Freitas

Universidade Federal de GoiásInstituto de Informática

Introdução

Neste trabalho será apresentado como é feita a leitura, escrita e consistência no Cassandra.Desenvolveremos seus conceitos e como são aplicados na prática.

Escrita - Banco de Dados Relacional

- Tabelas estruturadas para manter o mínimo de duplicidade de dados.

- Para satisfazer uma consulta os dados são armazenados em várias tabelas relacionadas que aderem a uma estrutura pré-definida.

- Por causa da estrutura a escrita tem um elevado custo,e o servidor tem que fazer trabalhos adicionais para garantir a integridade dos dados através de várias tabelas relacionadas.

Escrita - Cassandra-Escreve primeiro em um registro "log" (para maior

durabilidade)

-Depois escreve em uma estrutura de tabela na memória denominada por memtable.

-Cassandra pode alocar dinamicamente a quantidade certa de memória para o memtable ou o usuário pode gerenciar a quantidade de memória que está sendo utilizada.

Escrita - Cassandra-Quando o conteúdo da memtable exceder um

limite configurável, os dados da memtable, que inclui índices secundários, é colocado em uma fila para ser descarregado para o disco. Você pode configurar o tamanho da fila, alterando memtable_flush_queue_size no cassandra.yaml.

-Escritas são agrupadas na memória e periodicamente gravadas em disco.

-Grava em uma tabela SSTable (sorted string table).

Escrita - Cassandra-Memtable e SSTable são mantidas por família de

colunas.

-Memtable é organizada em ordem de classificação por chave de linha e descarregada sequencialmente para a SSTable (não ocorre buscas aleatórias como em bancos de dados relacional).

-SSTable são imutáveis (elas não são escritas novamente após terem sido descarregadas).

Escrita - Cassandra-Uma linha normalmente é armazenada em vários

arquivos SSTable.

-A escrita é bem sucedida uma vez que é escrita no log e na memória, gerando o mínimo de I/O no disco no momento de gravação.

-Cada SSTable tem um filtro Bloom (estrutura em memória) associado a ele que verifica se uma chave de linha solicitada existe no SSTable antes de fazer qualquer busca no disco.

Bloom Filters- Ferramenta muito útil para evitar a execução de

cálculos caros sem a sobrecarga de memória total de um padrão de mapa/dicionário.

- É uma estrutura de dados probabilística que é usada para testar se um elemento é um membro de um conjunto.

Escrita - Cassandra

Como Cassandra armazena dadosNo memtable, os dados são organizados em ordem de

classificação por chave de linha.

- Para maior eficiência, Cassandra não repete os nomes

das colunas na memória ou na SSTable. Por exemplo, a

seguinte escrita ocorre:

escrever (k1, c1: v1)

escrever (k2, c1: v1 c2: v2)

escrever (k1, c1: v4 c3: v3 c2: v2)

Como Cassandra armazena dados- Na memtable, o Cassandra armazena esses dados depois

de receber o escreve:

k1 c1: v4 c2: v2 c3: v3

k2 c1: v1 c2: v2

- No commit log no disco, o Cassandra armazena os dados

e depois de receber o escreve:

k1, c1: v1

k2, c1: v1 c2: v2

k1, c1: v4 c3: v3 c2: v2

Como Cassandra armazena dados- No SSTable no disco, o Cassandra armazena esses dados

após a saída do memtable:

k1 c1: v4 c2: v2 c3: v3

k2 c1: v1 c2: v2

Escrita

Atualização índices secundários- Para atualizar índices secundários, Cassandra anexa no

commit log, atualiza a memtable e atualiza os índices secundários.

- Escrever em uma tabela que contém índices secundários leva um custo extra.

- Quando uma coluna é atualizada, o índice secundário é atualizado.

Gerenciamento de dados armazenados

- Cassandra escreve em famílias de colunas para o disco usando diretório formado de arquivos e nomes.

- Cassandra cria um subdiretório para cada família de colunas, que permite que um administrador escolha uma família de coluna e transfira ela para uma unidade de sua escolha, por exemplo, famílias de colunas que tem grande acesso, coloca em uma mídia de disco mais rápida (SSD).

Compactação-Cassandra periodicamente funde SSTables junto em

SSTables maiores, usando o processo chamado de compactação.

-Compactação mescla as linhas das SSTables, remove colunas excluidas, reconstroi os índices primários e secondários.

-A leitura é prejudicada quando está ocorrendo uma compactação, porém após essa compactação melhora a leitura uma vez que há menos SSTables no disco que precisam ser verificados.

Excluir- Ao excluir uma coluna no Cassandra, devemos estar

cientes de algumas coisas que podem acontecer que são diferente do banco de dados relacional.

- Após supostamente deletar uma coluna, ela não é eliminada imediatamente, em vez disso existe um marcador chama tombstone escreve um novo estado para essa coluna (morta). As colunas marcada como mortas, após por um período de tempo que é configurado são permanentemente eliminadas pelo processo de compactação.

- Existe um ponto de falha! Qual é?!

Excluir - Resposta!- A coluna supostamente excluída pode voltar dos mortos

e reaparecer! Isso ocorre que quando uma máquina réplica está caída no momento da exclusão, ela deveria receber a exclusão assim que voltar a ativa, porém se a máquina réplica ficar indisponível por um tempo maior que o configurado para manter a tombstone (definido por gc_grace_seconds, um valor definido na tabela), o nó poderá perde a exclusão completa e replicar os dados "apagados", uma vez que ela vem de volta. Para evitar que colunas excluídas voltem a aparecer, os administradores devem executar um reparo em cada nó do cluster (padrão a cada 10 dias).

Escrita - Consistência- Quando você faz uma gravação em Cassandra, o nível de

consistência especifica em quantas réplicas a escrita deve ser bem sucedido antes de retornar um reconhecimento para o aplicativo do cliente.

- QUORUM é um bom meio termo garantindo a consistência forte, mas ainda tolerar algum nível de fracasso. O quorum é calculado como (arredondado para o número inteiro inferior): ( replication_factor / 2 ) + 1

Escrita - Consistência- Por exemplo, com um factor de replicação de 3, um

quorum é 2 (pode tolerar uma réplica para baixo). Com um fator de replicação de 6, o quórum é de 4 (pode tolerar duas réplicas para baixo).

Escrita - Nível ConsistênciaAny

- A gravação deve ser escrita em pelo menos um nó. Se todos os nós da réplica para a row key estão caidos, a escrita ainda pode ter sucesso uma vez que por Hinted Handoff foi escrito. Note que, se todos os nós réplicas cai na hora da escrita, uma escrita com consistência ANY, não poderá ser lida até os nós replicas para aquela row key tiverem recuperados ( da morte). Obs: menor consistência, maior disponibilidade.

One

- A gravação deve ser gravado no log de confirmação e na tabela de memória de pelo menos um nó réplica.

Escrita - Nível ConsistênciaTwo

- A gravação deve ser escrito no log e na tabela de memória de pelo menos dois nós de réplica.

Three

- A gravação deve ser escrito no log de e na tabela de memória de pelo menos dois nós de réplica.

QUORUM

- A gravação deve ser gravada no log de confirmação e tabela de memória em um quorum de nós de réplica.

Escrita - Nível ConsistênciaEACH_QUORUM

- A gravação deve ser gravado no log de confirmação e na tabela de memória em um quorum de nós de réplica e em todos os data center.

LOCAL_QUORUM

- A gravação deve ser gravado no log de confirmação e na tabela de memória em um quorum de nós de réplica no mesmo data center como o nó coordenador.

Escrita - Nível ConsistênciaALL

- A gravação deve ser gravado no log de confirmação e tabela de memória em todos os nós do cluster de réplica para essa chave de linha. Obs: maior consistência, menor disponibilidade.

Exemplo CQL:

INSERT INTO Alunos(nome,matrícula) VALUES ('FFFF', 65535) USING CONSISTENCY LOCAL_QUORUM;

Hinted HandoffHinted Handoff é uma parte opcional de escrever em Cassandra , ativado por padrão, com dois propósitos:

-Permitir o Cassandra oferecer disponibilidade máxima de gravação, quando a consistência não é necessária.

-Melhora a consistência da resposta depois de interrupções temporárias, tais como falhas de rede.

Hinted Handoff- Quando uma gravação é realizada e um nó de réplica não

responde a solicitação de gravação por algum motivo, o coordenador irá armazenar um “lembrete” localmente, indicando repetir o procedimento.

- Quando o coordenador descobre através do gossip que o nó que estava indisponível voltou a ativa, ele reenviará as linhas de dados correspondente ao lembrete.

Hinted Handoff - Consistência.- A gravação com Hinted Handoff não satisfaz as

consistência de nível ONE, QUORUM, ou ALL por si só. A consistência ANY por ser satisfeita com Hinted Handoff.

O Hinted Handoff não conta como uma gravação com sucesso em uma réplica. Por exemplo, uma consistência de nível TWO, uma réplica é gravada com sucesso, porém todas as outras não teve sucesso, então cria-se "lembretes" para todas as operações não sucedidas, mas a operação como um todo falha.

Hinted Handoff - Gravação Externa- Aplicativos que desejam que o Cassandra aceite uma

escrita mesmo quando todas as réplicas estão indisponíveis (por isso mesmo o nível de consistência ONE por exemplo, não pode ser satisfeito), o Cassandra fornece consistência de nível ANY.

- A consistência de nível ANY garante que a gravação é durável e poderá ser lida quando a réplica indisponível torna-se disponível e recebe novamente do lembrete.

Leitura Realiza leituras aleatórias em paralelo em SSD's com latência extremamente baixa.

Discos rotacionais não são recomendados.

Lê, e também escreve, dados por chave primária.

Verifica primeiro o Bloom filter. Cada SSTable tem um Bloom filter associado a ela que verifica se algum dado da linha solicitada existe na SSTable antes de fazer qualquer E/S de disco.

Em seguida, o Cassandra checa o key cache global. Se os dados solicitados não estão no key cache, é feita uma busca binária no index summary para encontrar uma linha. Por padrão, uma row key de cada 128 é amostrada do índice primário para criar o index summary.

Frequência de amostragem configurável: index_interval no arquivo cassandra.yaml.

Finalmente, o Cassandra realiza um simples seek e uma leitura sequencial de colunas no SSTable se as colunas forem contíguas, e retorna o conjunto de resultados.

Leitura

LeituraLeituras de disco ocorrem a nível de bloco. Uma leitura de disco do bloco de índice corresponde a entrada amostrada mais próxima. E assim o Cassandra lê uma linha, com alguma seleção de colunas ou de um intervalo de colunas.

Este processo, em conjunto com a pesquisa rápida de dados através de índices primários e secundários faz o Cassandra muito eficiente em leituras quando comparado com outros sistemas de armazenamento, mesmo para casos read-heavy.

O carregamento e amostragem eficientes de índices das SSTables nas memórias cache permite que cada nó tenham tempos reduzidos de startup/bootup.

Caminho da leitura

Quando uma requisição de leitura de uma row chega a um nó, a row tem de ser combinada a partir de todas as SSTables nesse nó que contêm as colunas row em questão, bem como de quaisquer memtables unflushed, para produzir os dados solicitados.

O diagrama a seguir mostra o caminho de leitura de uma requisição de leitura:

Caminho de leitura

Como as atualizações e a compactação afetam a leituraO tipo de estratégia de compactação que o Cassandra realiza em seus dados é configurável e pode afetar significativamente a performance da leitura.

Usando o SizeTieredCompactionStrategy tende a causar a fragmentação de dados quando as linhas são atualizadas frequentemente. O LeveledCompactionStrategy foi projetado para evitar a fragmentação sob esta condição.

Com a fragmentação a performance torna-se inconsistente, pois uma linha poderia, no pior caso, ter cada coluna em um SSTable diferente.

Como as atualizações e a compactação afetam a leituraO LeveledCompactionStrategy garante que 90% de todas as leituras sejam feitas em apenas uma SSTable ( assumindo que as linhas sejam de tamanho quase uniforme).

Para prevenir que a velocidade de leitura se deteriore, a compactação é executada em background sem alguma operação de E/S aleatória.

Como a compactação é intensiva em operações de E/S, se durante sua execução for feita uma leitura para um dado que não se encontra na cache, a performance será prejudicada.

Como a compressão afeta a leituraDependendo das características da tabela, comprimindo seus dados pode resultar em:

● 2x-4x de redução do tamanho

● 25-35% melhor performance na leitura

● 5-10% melhor performance na escrita

SnappyCompressor oferece compressão/descompressão mais rápida, e é recomendado para casos read-heavy.

A compressão reduz bastante as operações de E/S para a leitura.

Como o cache afeta a leituraTipicamente as leituras são mais rápidas quando os dados em maior demanda cabem na memória.

Embora todos sistemas de armazenamento modernos usam alguma forma de cache, nem todos decaem suavemente quando a memória acaba e operações de E/S de disco são necessárias.

O Cassandra possui um sistema de caching internamente, do qual a performance da leitura é beneficiada. O cache pode ser de uma chave, ou de uma linha.

Consistência na LeituraO nível de consistência especifica quantas réplicas devem responder antes de retornar o resulta para o cliente.

O Cassandra então escolhe pelo timestamp o dado mais recente entre as réplicas que responderam.

Níveis de Consistência na LeituraONE

-Retorna uma resposta pela réplica mais próxima (determinada pelo snitch). Por default, um read-repair é executa no plano de fundo para dar consistência a outras réplicas.

TWO

-Retorna o dado mais recente das duas réplicas mais próximas.

THREE

-Retorna o dado mais recente das três réplicas mais próximas.

Níveis de Consistência na LeituraQUORUM

-Retorna o dado mais recente depois que um quorum de réplicas responder.

LOCAL_QUORUM

-Retorna o dado mais recente depois que um quorum de réplicas no data center atual forem reportadas pelo coordinator.

EACH_QUORUM

-Retorna o dado mais recente depois que um quorum de réplicas em cada data center responder.

Níveis de Consistência na LeituraALL

-Retorna o dado mais recente depois que todas as réplicas responderem. A leitura falha se uma réplica não responder.

Exemplo CQL:

SELECT * FROM Alunos where matricula = 999 USING CONSISTENCY THREE;

Transações e controle de concorrência

O Cassandra não oferece transações totalmente ACID, o comportamento transacional padrão em um bancos de dados relacionais:

○ Atômico: Tudo em uma transação sucede ou uma transação inteira revertida para o estado anterior.

○ Consistente: Uma transação não pode deixar o banco de dados em um estado inconsistente.

○ Isolado: Transações não podem interferirem entre si.○ Durável: Transações completadas persistem após falhas ou

quedas do servidor.

Transações e controle de concorrência

Atomicidade no Cassandra: escrita atômica a nível de linha

O Cassandra não suporta transações no sentido de juntar múltiplas atualizações de linha em uma operação tudo-ou-nada. Nem reverte transações quando uma escrita sucede em uma réplica, mas falha em outra. É possível o Cassandra reportar falha na escrita, mas ainda persistir a escrita na réplica.

Consistência no Cassandra: Não suporta joins ou chaves estrangeiras, e consequentemente não oferece consistência no sentido do ACID. Não há dependências transacionais ou locking quando há atualização concorrente de várias linhas ou tabelas.

O Cassandra suporta tuning entre disponibilidade e consistência.

Transações e controle de concorrência

Isolação no Cassandra: No Cassandra 1.1 era possível um usuário ler parcialmente uma linha enquanto outro estava atualizando-a.

Atualmente uma isolação completa a nível de linha está colocada, tal que qualquer usuário só poderá enxergar uma linha depois que ela for atualizada por completo.Isso dá ao Cassandra o suporte transacional AID.

Durabilidade no Cassandra: Todas escritas para uma réplica são gravadas ambos na memtable e no commit log no disco antes de serem reconhecidas como sucesso. Se ocorrer uma queda ou falha do servidor antes da memtable ser flushed, o commit log é repetido ao reiniciar para recuperar escritas perdidas. Em adição a durabilidade local, a replicação dos dados fortalecem a durabilidade.

Consistência

No Cassandra, consistência refere-se a quão atualizada e sincronizada é uma linha de dado em todas suas réplicas. O Cassandra estende o conceito de consistência eventual com o oferecimento de consistência tunável. Para uma dada operação de escrita ou leitura, a aplicação cliente decide quão consistente o dado deve ser.

Em adição a consistência tunável, o Cassandra tem três mecanismos embutidos para assegurar que o dado permaneça consistente em todas réplicas.

Se consistência é a maior prioridade, você pode garantir que uma leitura semple reflite a escrita mais recente, usando a seguinte formula:

(nos_escritos + nos_lidos) > replication_factor (consistência forte se verdadeiro, fraca caso contrário).

Reparos na Consistência.O Cassandra internamente possui três formas de reparo para assegurar que os dados continuem consistentes por todas as réplicas. São elas:

■ Read Repair■ Hinted Handoff■ Anti-Entropy Node Repair

-Read Repair: Quando uma leitura é feita, algumas réplicas não são escolhidas. Completada a leitura, o coordinator também seleciona estas e checa qual tem o dado mais recente. Se houver inconsistência, o coordinator emitirá escritas para todas réplicas desatualizadas.

Para cada tabela, há uma chance read_repair_chance de um read repair ser executado depois de uma leitura.

Reparos na Consistência-Hinted handoff: reparo para a escrita ( já visto)

-Anti-Entropy Node Repair: O comando nodetool repair repara inconsistências por todas as réplicas para um dado intervalo de dados. Também remove tombstones. Recomenda-se executá-lo ao menos uma vez, para cada nó, a cada gc_grace_seconds para assegurar que as remoções são devidamente tratadas no cluster.

repair keyspace [table] [-pr]

Benchmarking High Performance I/O with SSD for Cassandra on AWS - NetFlix

Benchmarking High Performance I/O with SSD for Cassandra on AWS - Netflix

Netflix Application Benchmark

Storing 8.5TB data

The two configurations compared were:

Existing system: 48 Cassandra on m2.4xlarge. 36 EVcache on

m2.xlarge.

SSD based system: 12 Cassandra on hi1.4xlarge.

Benchmarking High Performance I/O with SSD for Cassandra on AWS - Netflix

Referências

http://techblog.netflix.com/2012/07/benchmarking-high-performance-io-with.html

http://www.allthingsdistributed.com/2008/12/eventually_consistent.html

http://www.datastax.com/docs/1.2/dml/index

http://www.datastax.com/docs/1.2/dml/about_writes

http://www.datastax.com/docs/1.2/dml/about_reads

http://jonathanhui.com/how-cassandra-read-persists-data-and-maintain-consistency

http://www.datastax.com/dev/blog/modern-hinted-handoff

http://abel-perez.com/cassandra-hinted-handoff

http://www.royans.net/arch/cassandra-what-is-handedhintoff/

http://www.datastax.com/docs/1.2/dml/data_consistency

http://www.slideshare.net/jbellis/what-every-developer-should-know-about-database-scalability

http://www.slideshare.net/DataStax/understanding-data-consistency-in-apache-cassandra

http://www.slideshare.net/heukirne/cassandra-db-6144559#btnNext

http://www.slideshare.net/benjaminblack/introduction-to-cassandra-replication-and-consistency

http://www.datastax.com/support-forums/forum/cassandra

http://zopub.com/download?doc_id=519

https://www.dropbox.com/s/4mngqujyzgb26j5/Cassandra%20The%20Definitive%20Guide.pdf

http://brianoneill.blogspot.com.br/

http://www.edwardcapriolo.com/roller/edwardcapriolo/

http://www.ibm.com/developerworks/library/os-apache-cassandra/index.html