Apache Cassandra: armazenando dados em um cluster

5.1 Distribuição de dados

Vamos considerar como os dados são distribuídos dependendo da chave entre os nós do cluster. Cassandra permite que você defina uma estratégia de distribuição de dados. A primeira dessas estratégias distribui dados dependendo do valor da chave md5 - um particionador aleatório. A segunda leva em consideração a representação de bits da própria chave - a marcação ordinal (particionador ordenado por byte).

A primeira estratégia, na maioria das vezes, dá mais vantagens, já que você não precisa se preocupar com distribuição uniforme de dados entre servidores e tais problemas. A segunda estratégia é usada em casos raros, por exemplo, se forem necessárias consultas de intervalo (varredura de intervalo). É importante observar que a escolha dessa estratégia é feita antes da criação do cluster e de fato não pode ser alterada sem uma recarga completa dos dados.

Cassandra usa uma técnica conhecida como hashing consistente para distribuir dados. Essa abordagem permite distribuir dados entre os nós e garantir que, quando um novo nó for adicionado e removido, a quantidade de dados transferidos seja pequena. Para fazer isso, cada nó recebe um rótulo (token), que divide o conjunto de todos os valores-chave md5 em partes. Como RandomPartitioner é usado na maioria dos casos, vamos considerá-lo.

Como eu disse, RandomPartitioner calcula um md5 de 128 bits para cada chave. Para determinar em quais nós os dados serão armazenados, basta passar por todos os rótulos dos nós do menor ao maior e, quando o valor do rótulo for maior que o valor da chave md5, esse nó, juntamente com um número de nós subseqüentes (na ordem dos rótulos) é selecionado para armazenamento. O número total de nós selecionados deve ser igual ao fator de replicação. O nível de replicação é definido para cada keyspace e permite ajustar a redundância de dados (redundância de dados).

Antes que um nó possa ser adicionado ao cluster, ele deve receber um rótulo. A porcentagem de chaves que cobrem a lacuna entre este rótulo e o próximo determina quantos dados serão armazenados no nó. Todo o conjunto de rótulos de um cluster é chamado de anel.

Aqui está uma ilustração usando o utilitário interno nodetool para exibir um anel de cluster de 6 nós com rótulos espaçados uniformemente.

5.2 Consistência de dados ao escrever

Os nós do cluster Cassandra são equivalentes e os clientes podem se conectar a qualquer um deles, tanto para gravação quanto para leitura. As solicitações passam pelo estágio de coordenação, durante o qual, tendo descoberto com a ajuda da chave e da marcação em quais nós os dados devem estar localizados, o servidor envia solicitações a esses nós. Chamaremos o nodo que realiza a coordenação de coordenador , e os nodos que forem selecionados para salvar o registro com a chave fornecida, os nodos réplica . Fisicamente, um dos nós de réplica pode ser o coordenador - depende apenas da chave, marcação e rótulos.

Para cada requisição, tanto de leitura quanto de escrita, é possível definir o nível de consistência dos dados.

Para uma gravação, esse nível afetará o número de nós de réplica que aguardarão a confirmação da conclusão bem-sucedida da operação (dados gravados) antes de devolver o controle ao usuário. Para um registro, existem estes níveis de consistência:

• UM - o coordenador envia requisições para todos os nós da réplica, mas após aguardar a confirmação do primeiro nó, devolve o controle ao usuário;
• DOIS - o mesmo, mas o coordenador aguarda a confirmação dos dois primeiros nós antes de retornar o controle;
• TRÊS - semelhante, mas o coordenador aguarda a confirmação dos três primeiros nós antes de retornar o controle;
• QUORUM - é recolhido um quórum: o coordenador está à espera de confirmação do registo de mais de metade dos nós de réplica, ou seja, round (N/2) + 1, onde N é o nível de replicação;
• LOCAL_QUORUM - O coordenador está aguardando a confirmação de mais da metade dos nós de réplica no mesmo datacenter onde o coordenador está localizado (potencialmente diferente para cada solicitação). Permite eliminar os atrasos associados ao envio de dados para outros centros de dados. As questões de trabalhar com muitos centros de dados são consideradas neste artigo de passagem;
• EACH_QUORUM - O coordenador está aguardando a confirmação de mais da metade dos nós de réplica em cada datacenter, de forma independente;
• ALL - o coordenador aguarda a confirmação de todos os nós de réplica;
• ANY - torna possível gravar dados, mesmo que todos os nós de réplica não estejam respondendo. O coordenador espera pela primeira resposta de um dos nós de réplica ou pelos dados a serem armazenados usando um handoff sugerido no coordenador.

5.3 Consistência dos dados durante a leitura

Para leituras, o nível de consistência afetará o número de nós de réplica que serão lidos. Para a leitura, existem estes níveis de consistência:

• UM - o coordenador envia solicitações para o nó de réplica mais próximo. O resto das réplicas também são lidas para reparo de leitura com a probabilidade especificada na configuração do cassandra;
• DOIS é o mesmo, mas o coordenador envia solicitações para os dois nós mais próximos. O valor com o maior timestamp é escolhido;
• TRÊS - semelhante à opção anterior, mas com três nós;
• QUORUM - é recolhido um quorum, ou seja, o coordenador envia pedidos para mais de metade dos nós de réplica, ou seja, round (N/2) + 1, onde N é o nível de replicação;
• LOCAL_QUORUM - um quorum é coletado no datacenter em que ocorre a coordenação e os dados com o carimbo de data/hora mais recente são retornados;
• EACH_QUORUM - O coordenador retorna os dados após a reunião do quorum em cada um dos datacenters;
• ALL - O coordenador retorna dados após a leitura de todos os nós de réplica.

Assim, é possível ajustar os atrasos de tempo das operações de leitura e escrita e ajustar a consistência (tune consistência), bem como a disponibilidade (availability) de cada tipo de operação. Na verdade, a disponibilidade está diretamente relacionada ao nível de consistência de leituras e gravações, pois determina quantos nós de réplica podem cair e ainda assim serem confirmados.

Se o número de nodos de onde vem o reconhecimento de escrita, mais o número de nodos de onde é feita a leitura, for maior que o nível de replicação, então temos a garantia de que o novo valor sempre será lido após a escrita, e isso é chamado de consistência forte (consistência forte). Na ausência de consistência forte, existe a possibilidade de que uma operação de leitura retorne dados obsoletos.

Em qualquer caso, o valor eventualmente se propagará entre as réplicas, mas somente após o término da espera de coordenação. Essa propagação é chamada de consistência eventual. Se nem todos os nós de réplica estiverem disponíveis no momento da gravação, mais cedo ou mais tarde as ferramentas de recuperação, como leituras corretivas e reparo de nó anti-entropia, entrarão em ação. Mais sobre isso mais tarde.

Assim, com um nível de consistência de leitura e gravação de QUORUM, sempre será mantida uma consistência forte, e isso será um equilíbrio entre a latência de leitura e gravação. Com TODAS as gravações e UMA leitura, haverá consistência forte e as leituras serão mais rápidas e mais disponíveis, ou seja, o número de nós com falha nos quais uma leitura ainda será concluída pode ser maior do que com QUORUM.

Para operações de gravação, todos os nós de trabalho de réplica serão necessários. Ao escrever ONE, lendo ALL, também haverá consistência estrita, e as operações de gravação serão mais rápidas e a disponibilidade de gravação será grande, pois será suficiente confirmar apenas que a operação de gravação ocorreu em pelo menos um dos servidores, enquanto a leitura é mais lenta e requer todos os nós de réplica. Se um aplicativo não tiver um requisito de consistência estrita, será possível acelerar as operações de leitura e gravação, bem como melhorar a disponibilidade definindo níveis de consistência mais baixos.