examinando o ciclo de vida de lápides em Apache Cassandra

este post é a primeira parte de uma série de posts em blogs sobre o ciclo de vida e gestão de lápides.

apagar e expirar dados em Cassandra é algo que você deve planejar cuidadosamente. Especialmente se estiver prestes a apagar uma grande quantidade de dados ao mesmo tempo. Sem planejamento adequado, isso pode trazer problemas para o cluster como um aumento na leitura-latência e pegada de Uso do disco. Ao longo deste post, vou descrever uma maneira de lidar com isso e suas advertências.Primeiro, vamos rever o básico. Em Cassandra, os arquivos de dados (SSTables) existentes no disco são Arquivos imutáveis. Quando estamos apagando algo em Cassandra, um novo SSTable é criado que contém um marcador. Este marcador indica qual partição, linha ou célula foi removida juntamente com a data-limite para essa remoção. Este marcador de exclusão é chamado de lápide.

os dados apagados e a lápide podem coexistir no disco durante um período chamado gc_grace_seconds, que é por padrão 10 dias. Durante este tempo, embora os dados ainda possam existir na unidade, não é devolvido ao cliente se questionado. O que significa que do ponto de vista do cliente, os dados são apagados assim que você executar a declaração de delete. No entanto, de um ponto de vista operacional, tanto os dados como a lápide ainda podem existir e ocupar espaço no disco. Estes dados apagados que ainda existem no disco são chamados de “dados sombreados.”

N. B.: No parágrafo anterior eu digo que os dados e as lápides “ainda podem coexistir em disco” (ênfase no “pode”) porque se a compactação ocorre que envolve os dados e as lápides, então os dados são despejados. Mas a lápide permanecerá se gc_grace_segundos não tiver passado.

the gc_grace_seconds is a safety mechanism to ensure that the tombstone has enough time to replicate to all nodes that have a replica of the shadowed data. Para que este mecanismo de segurança seja bem sucedido, você deve ser capaz de reparar o conjunto a cada gc_grace_seconds. O que significa que se você estiver usando os 10 dias padrão para gc_grace_seconds, uma reparação deve ser iniciada e concluída dentro de cada 10 dias. A reparação serve o propósito de evitar dados zombies no aglomerado. Eu não vou entrar nos detalhes de como isso pode acontecer, mas basicamente, dados zumbis ocorrem quando você apaga dados, mas ele retorna algum tempo depois.

depois de gc_grace_seconds ter passado, os dados e a lápide podem finalmente ser despejados do disco, recuperando o espaço em disco usado anteriormente por eles (Figura 1). A ETA para liberar o espaço em disco é um dos primeiros pontos que eu quero esclarecer neste post. Ao usar Cassandra, muitas pessoas acham este mecanismo surpreendente, isto é, que após a exclusão de dados, os dados ainda existem no disco. Esta confusão é geralmente clarificada rapidamente assim que as pessoas aprendem sobre lápides e gc_grace_seconds. No entanto, parece que os operadores tendem a pensar que os dados e as lápides são despejados logo após o gc_grace_seconds ter terminado. Na verdade, é essencial estar ciente de que isso pode não (e tende a não) ser verdade. Normalmente, demora mais do que gc_grace_segundos para que este despejo aconteça e o espaço em disco recuperado.

Figura 1-compactar dados sombreados com lápides expiradas e não expiradas

a expulsão mencionada acima acontece quando a compactação ocorre que envolve os SSTables que têm os dados sombreados e a lápide. Só então, os dados são efetivamente removidos, e o espaço em disco recuperado. É importante notar que mesmo que gc_grace_seconds tenha passado e o SSTable com os dados sombreados seja compactado com outro SSTable que não tenha a lápide, então os dados sombreados não são purgados. A mesma coisa acontece para os marcadores da lápide, isto é, se o SSTable com a lápide não é compactado com todos os SSTables que ainda têm os dados que foram apagados, então o tombstone não é despejado do disco. A razão por que isso acontece é que durante a compactação, Cassandra não sabe o que está nos SSTables que não estão envolvidos na compactação. Então não tem como saber que pode descartar os dados, já que não pode ver a lápide. Você pode ver isso na Figura 2 onde, embora gc_grace_seconds tenha passado por ambas as lápides, nada é despejado após a compactação.

Figura 2-compactando dados sombreados e suas lápides separadamente

devido ao uso do disco pelos dados e o marcador de lápide, a acumulação de lápides pode impactar a latência de leitura, porque Cassandra precisa ler muitos lápides antes de retornar dados ao vivo.

apagar dados normalmente não é um problema se estas supressões são pequenas e escassas. Porque, ao longo do ciclo de vida da compactação natural, Cassandra eventualmente recupera o espaço em disco e as lápides purgadas. No entanto, se você estiver apagando uma grande quantidade de dados ao mesmo tempo, isso cria muitas lápides e pode rapidamente impactar sua read-latência.

se você precisa excluir uma grande quantidade de dados em uma base ad-hoc, então há alguns passos no próximo post do blog que você pode tomar para mitigar os riscos.

e-mail

Autor

  • Pedro Gordo

Interessado em trabalhar com o Pedro? Marca uma chamada técnica.

Deixe uma resposta

O seu endereço de email não será publicado.