CASSANDRA

1. Introdução

Grandes corporações como Google e Amazon, foram as primeiras a descobrir a não adequação dos bancos de dados relacionais às necessidades de armazenamento de dados em larga escala levando-os ao enfrentamento destes novos desafios, com soluções alternativas como: Big-Table e Dynamo, nos quais foram diminuídas as garantias de maior consistência dos dados, por exemplo, oferecidas pelo modelo relacional.

Baseado nos modelos Big-Table desenvolvido pela Google e Dynamo da Amazon, a empresa Facebook desenvolveu a sua própria solução, e mais tarde abriu o seu código-fonte para comunidade, e atualmente o Cassandra é mantido pela Apache Foundation.

O Apache Cassandra é um das primeiras soluções dos sistemas NoSQL, e oferece escalabilidade e alta disponibilidade, sem ponto único de falha. Além de seu rendimento de gravação considerado muito alto e bom rendimento de leitura, o modelo de dados do Cassandra também oferece consistência ajustável e suporte de replicação.

2. Análise

Cassandra é um sistema de banco de dados distribuído para gerenciamento e armazenamento de grandes quantidades de dados estruturados espalhados em servidores de réplicas, enquanto a oferece alta disponibilidade e escalabilidade sem ponto único de falha. Em uma implementação de famílias de colunas NoSQL que suporta o modelo de dados Big-Table, e usa aspectos da arquitetura do Amazon Dynamo, esta solução atende positivamente a quesitos muito importantes como: alta escalabilidade e disponibilidade sem ponto único de falha, implementações da família de colunas NoSQL, rendimento de gravação muito alto e bom rendimento de leitura, linguagem de consulta semelhante a SQL (desde 0.8), suporte para procura por índices secundários e consistência ajustável e suporte para replicação.

2.1. O modelo de dados do Cassandra

Uma tabela do Cassandra é um mapa multidimensional distribuído e indexado por uma chave. O valor é um objeto altamente estruturado. A linha de uma tabela é uma string sem restrições de tamanho, apesar de tipicamente ter de 16 a 36 bytes. Cada operação em uma única chave de linha é atômica por réplica, não importando quantas colunas estão sendo lidos ou escritos. O modelo de dados consiste em colunas, linhas, famílias de colunas e keyspaces, onde:

Coluna – é a unidade mais básica do modelo de dados do Cassandra, contendo um nome, um valor e um registro de data e hora.

Linhas – é uma coleção de colunas rotuladas com um nome.

O Cassandra consiste em muitos nós de armazenamento e armazena cada linha em um único nó. Em cada linha, Cassandra sempre armazena as colunas classificadas por seus nomes. Usando esta ordem de classificação, o Cassandra permite consultas por fatia, nas quais, dada uma linha, os usuários podem recuperar um subconjunto de suas colunas que estejam em um dado intervalo de nomes de coluna. As colunas são agrupadas em conjuntos, chamados de famílias de colunas muito semelhante ao que acontece no Big-Table.

Famílias de Colunas – uma coleção de linhas rotuladas com um nome.

Keyspace – um grupo de várias famílias de colunas juntas. É um agrupamento lógico de famílias de colunas e fornece um escopo isolado para nomes.

Um exemplo de coluna. Conforme a figura:

Figura 1. Estrutura de uma coluna. Fonte: Cassandra: The Definitive Guide

2.2. Arquitetura

O Cassandra é um sistema distribuído. Ele consiste em vários nós e distribui os dados entre eles, ou divide-os em shards, na terminologia de bancos de dados. O Cassandra usa um algoritmo de hash para calcular o hash das chaves de cada item de dados armazenados nele, como por exemplo, nome da coluna, ID da linha. O intervalo de hash, ou todos os valores de hash possíveis (também chamados de keyspace), é dividido entre os nós no cluster do Cassandra. Em seguida o Cassandra designa cada item de dados ao nó, e esse nó é responsável por armazenar e gerenciar o item de dados.

3. Política de Segurança

Os administradores podem criar usuários que podem ser autenticados aos clusters de banco de dados Cassandra usando o comando CREATE USER. Internamente, Cassandra gerencia contas de usuários e acesso ao cluster de banco de dados usando senhas. As contas de usuário podem ser gerenciadas usando o Cassandra Query Language (CQL). Da mesma forma os administradores de banco de dados podem gerenciar as permissões dos usuários ao acesso de objetos, este gerenciamento é feito por um paradigma familiar GRANT/REVOKE.

3.1. Encriptação SSL

3.1.1. Criptografia Cliente – Para – Nó

A Criptografia Cliente-para- nó protege os dados em vôo de máquinas do cliente para um cluster de banco de dados usando SSL (Secure Sockets Layer). Ele estabelece um canal seguro entre o cliente e o nó coordenador. Todos os nós devem ter todos os certificados SSL relevantes em todos os nós.

Para ativar o SSL de cliente para nó, será necessário definir a configuração de encritptação no client_encryption_optionsnocassandra.yaml.

3.1.2. Criptografia Nó – Para – Nó

Este de tipo de criptografia usa o padrão TLS / SSL para autenticar e criptografar mensagens entre os nós em cluster do Cassandra, para proteção dos dados em trânsito entre os nós, e para evitar o acesso não autorizado ao controle de nós. A criptografia pode ser aplicada a todas as mensagens entre os nós, a apenas as mensagens que passam de um rack para outro, ou apenas as mensagens que passam de um datacenter para outro.

4. Tipo de Armazenamento

O Cassandra sempre armazena dados de forma que as colunas sejam classificadas de acordo com seus nomes. Isso facilita a procura de dados em uma coluna usando consultas de fatia, mas é mais difícil procurar dados em uma linha, a menos que o usuário use um particionador que preserve a ordem. Ao contrário da maioria dos sistemas, no Cassandra as operações de escritas são mais rápidas do que as operações de leitura, transferindo dados a cerca de 80-360 MB/s por nó. Para isso, ele usa duas técnicas. O Cassandra mantém a maior parte dos dados na memória do nó responsável. As atualizações são feitas na memória e gravadas no armazenamento persistente (sistema de arquivos) de forma lenta. No entanto, para evitar a perda de dados, ele grava todas as transações em um log de confirmação no disco. Ao contrário da atualização de itens de dados no disco, as gravações em logs de confirmação envolvem apenas anexação e, portanto, evitam o atraso de rotação ao gravar no disco. A menos que a gravação tenha solicitado consistência total, o Cassandra grava dados em nós suficientes sem resolver inconsistências de dados, resolvendo-as apenas na primeira leitura. Esse processo é chamado de “reparo na leitura”.

5. Política de Replicação

Cassandra usa a replicação para garantir alta disponibilidade e durabilidade. Cada item de dados é replicado em Host N, onde N é o fator de replicação configurado "por-instância". Cada chave k, é atribuída a um nó coordenador. O coordenador é responsável pela replicação dos itens de dados que se enquadram dentro do seu alcance. Para armazenamento local cada chave dentro de seu alcance, o coordenador replica essas chaves em N-1 nós no anel. Cassandra fornece ao cliente diversas opções para a forma de como os dados precisam ser replicados, além de fornecer várias políticas de replicação como "Rack Unaware", "Rack Aware" (dentro de um datacenter) e "Datacenter Aware". As Réplicas são escolhidas com base na política de replicação escolhida pela aplicação. Se determinada aplicação opta pela política de replicação "Rack Unaware" como estratégia de replicação, em seguida as réplicas não-coordenadoras são escolhidas por seleção N-1 como sucessores do coordenador dentro do anel. Para estratégias como "Rack Aware" e "Datacenter Aware " o algoritmo é mais envolvido ligeiramente. Sistema Cassandra elege um líder entre os seus nós utilizando um sistema chamado Zookeeper. Todos os nós ligados ao cluster contatam um líder, que informa aos outros nós em uma determinada faixa que eles são réplicas, e o líder faz um esforço centralizado para manter invariavelmente que nenhum outro nó seja responsável por uma faixa maior que N-1 no anel. O metadados sobre a faixa de um nó é responsável por armazenar em cache local em cada nó e de uma forma tolerante a falhas no interior do Zookeeper - desta forma um nó que fica offline e volta a subir sabe o que aconteceu e pelo o que era responsável. Cada nó está ciente de todos os outros nós do sistema e, portanto, a gama de que são responsáveis. Cassandra dá garantias de durabilidade em a presença de falhas de nós e particionamento de rede e relaxamento dos requisitos de Quorum. Falhas em datacenters podem ocorrer devido à falta de energia, falhas no sistema de refrigeração, falhas de rede, e desastres naturais. O Cassandra está configurado de tal forma que cada linha é replicada em vários centros de dados. Essencialmente, a lista de preferência de uma chave é construída de tal forma que os nós de armazenamento estão espalhados por múltiplos datacenters. Estes datacenters são conectados através links de rede de alta velocidade. Este esquema de replicação através de vários datacenters permite lidar com datacenters completamente em falhas sem nenhuma paralização total do sistema.

5.1 Níveis de Consistência das Réplicas

O sistema de replicação proposto pelo gerenciador Cassandra inclui diversos níveis de consistência, que variam de zero (conhecido como dedos cruzados, quando não há verificação de consistência) a todos, controlando o valor de todas as réplicas para serem sempre consistentes.

O número de réplicas padrão do Cassandra é três, para permitir a identificação mínima de um valor inserido incorretamente (dois valores corretos e um incorreto), mas esse valor pode ser alterado facilmente nos arquivos de configuração. A estrutura que recebe os dados gravados é o commit log, que é o primeiro local por onde passam os dados e, posteriormente, os dados são encaminhados para uma estrutura de tabela em memória, denominada memory table. Para qualquer dada operação de escrita e de leitura, o cliente da aplicação decide quais dos níveis de consistência listados a seguir a operação deve ter.

ONE (1) - Na escrita garante que o dado foi escrito em um commit log e uma tabela de memória de ao menos uma réplica antes de responder ao cliente. Na leitura, o dado será retornado a partir do primeiro nó onde a chave buscada foi encontrada. Essa prática pode resultar em dados antigos sendo retornados, porém, como cada leitura gera uma verificação de consistência em background, consultas subsequentes retornarão o valor correto do dado;

QUORUM (Q) - Na escrita garante que o dado foi escrito em fator_replicao/2+1, que é determinado pelo arredondamento para baixo do valor do fator de replicação escolhido dividido por dois e acrescido de uma unidade. Na leitura retorna o valor mais recente lido de fator replicao/2 + 1 réplicas. As réplicas restantes são sincronizadas em background;

ALL (N) - Garante que operações de leitura e escrita envolverão todas as réplicas. Assim, qualquer nó que não responda às consultas fará as operações falharem.

Vale ressaltar também outros dois níveis de consistência que não foram mencionados previamente, os quais são:

Local Quorum e Each Quorum. Eles são níveis de consistência nas operações que são reservadas para data centers. No Local Quorum, a escrita deve ser efetivamente concluída no commitlog e na memory table no valor de quorum nos nós de replicação do mesmo data center do coordenador da operação, evitando o tempo de latência da comunicação entre os diferentes data centers. Já no nível Each Quorum cada um dos data centers deve ter a quantidade mínima do quorum para que a operação seja concluída com sucesso, garantindo maior consistência aos dados.

6. Política de Disponibilidade

Um controlador de tablet identifica a falha numa réplica quando esta não

responde a uma requisição Quando a falha é identificada o sistema toma uma das

duas providencias [3, 5]:

1. Caso a réplica falha não seja uma réplica mestre, o sistema cria mais uma réplica no datacenter onde a falha ocorreu, os dados da nova replica são copiados de outro centro de dados. Enquanto o processo de copia é executado, as requisições que seriam feitas à réplica falha, são encaminhadas para uma sadia. Assim, não há prejuízo para o aspecto de disponibilidade.

2. Caso a réplica falha seja uma réplica mestre, as requisições de escrita são bloqueadas para aquele objeto (afetando a disponibilidade), o sistema elege uma nova réplica para ser a réplica mestre, o sistema requisita o YMB para aplicar as atualizações necessárias na replica eleita. Ao finalizar

as operações de atualização, o sistema desbloqueia as requisições de escrita.

7. Detecção de Falhas

Detecção de falhas é um mecanismo pelo qual um nó pode localmente determinar se qualquer outro nó do sistema está para online ou offline. Na detecção de falhas do sistema Cassandra, também é utilizada para evitar tentativas de comunicação com os nós inacessíveis durante várias operações. Cassandra usa uma versão modificada do  Accrual Failure Detector. A ideia de um acumulador de detecção falhas é que o módulo de detecção de falhas não emita um valor booleano indicando que um nó está online ou offline. Ao invés vez disto, o módulo de detecção de falhas emite um valor que representa um nível de suspeita para cada um dos nós monitorados. Este valor é definido como  (phi). A idéia básica é a de expressar o valor de  em uma escala dinamicamente ajustada para retratar a rede e carregar as condições nos nós monitorados. O número  tem o seguinte significado: Dado algum limite , e assumindo que decidimos suspeitar de um nó A, quando = 1, então a probabilidade de que vamos cometer um erro (ou seja, a decisão será contrária no futuro pela recepção de um heartbeat mais tarde) é cerca de 10 %.

A probabilidade é de cerca de 1 % com  = 2, 0,1 % de  = 3, e assim por diante. Cada nó no sistema mantém uma janela deslizante de vezes entre chegadas de mensagens de respostas de outros nós do cluster. A distribuição destes tempos entre chegadas é determinado e  é calculado. Embora o papel inicial sugira que a distribuição é aproximada pela distribuição Gaussiana, encontramos a distribuição Exponencial para ter uma melhor aproximação, por causa da natureza do canal respostas e seu impacto na latência. Para o nosso conhecimento nossa implementação da detecção de falhas de acréscimo de uma resposta baseada configuração é a RST de sua espécie. Detectores de falhas Provisão são muito bons, tanto a sua precisão e a sua velocidade e eles também se ajustam bem às condições da rede e carga do servidor condições.

8. Websites / Empresas que Utilizam

Cassandra está em uso por empresas que possuem grande necessidade de escalabilidade de armazenamento como: Adobe, Aol, Barracuda Networks, Best-Buy, Cisco, Cloudkick, Constant Contact, Digg, eBay, , Reddit, OpenX, Ooyala, Urban Airship, Urbisoft, Twitter

Referências

Avinash Lakshman and Prashant Malik (2009) “Cassandra - A Decentralized Structured Storage System”, http://www.cs.cornell.edu/Projects/ladis2009/papers/Lakshman-ladis2009.PDF

Srinath Perera (2012), "Considerações sobre o Banco de Dados Apache Cassandra", https://www.ibm.com/developerworks/br/library/os-apache-cassandra/#resources

Xavier Défago, Peter Urban, Naohiro Hayashibara, Takuya Katayama, "The  accrual failure detector.", RR IS-RR-2004-010, Japan Advanced Institute of Science and Technology,

páginas 66 - 78, 2004.

The Apache Cassandra Project, http://cassandra.apache.org/

DataStax Corpotarion (2013), “White Paper”, http://www.datastax.com/what-we-offer/products-services/datastax-enterprise/apache-cassandra

Dário Saraiva de Melo Pinheiro (2013), “ANANÁLISE COMPARATIVA SOBRE A CONSISTÊNCIA DE BANCO DE DADOS NAS NUVENS”, página 16