a Cassandra gera lápides quando apaga dados. Sob algumas circunstâncias, o excesso de lápides pode causar longas pausas GC, latência, falhas de leitura, ou fora de erros de heap. Este artigo fornece conselhos para a gestão de lápides.

Índice

O que é uma lápide?

em Cassandra, os dados apagados não são imediatamente purgados do disco. Em vez disso, Cassandra escreve um valor especial, conhecido como uma lápide, para indicar que os dados foram apagados. Tombstones impedem que os dados apagados sejam devolvidos durante as leituras, e eventualmente permitirá que os dados sejam descartados através da compactação.

Tombstones são escritos-eles passam pelo caminho normal de escrita, ocupam espaço no disco, e fazem uso dos mecanismos de consistência de Cassandra. Lápides podem ser propagadas através do aglomerado através de dicas e reparos. Se um cluster é gerenciado corretamente, isso garante que os dados permanecerão apagados, mesmo se um nó estiver em baixo quando a delete é emitida.

túmulos são gerados por:

• apagar declarações
• configurar TTLs
• inserir valores nulos
• inserir dados em partes de uma colecção.

Qual é o ciclo de vida normal das lápides?

Tombstones são escritos com um timestamp. Em circunstâncias ideais, lápides (e seus dados associados) serão deixadas cair durante compactações depois de uma certa quantidade de tempo ter passado.

os três critérios seguintes devem ser cumpridos para que as lápides sejam removidas:

• as lápides foram criadas há mais de gc_ grace_seconds.a tabela que contém a lápide está envolvida numa compactação.
• todos os elementos que possam conter os dados relevantes estão envolvidos na compactação.

cada tabela tem uma configuração gc_grace_seconds. Por padrão, este é definido para 864000, o que é equivalente a 10 dias. A intenção é proporcionar tempo para o cluster alcançar consistência através de reparos (e, portanto, impedir a ressurreição de dados apagados).

Tombstones só serão largados através de uma compactação se todos os sstables que possam conter os dados relevantes estiverem envolvidos na compactação. Se tiver decorrido muito tempo entre a escrita dos dados originais e a emissão da DELETE, Isso torna-se menos provável:

• A Estratégia de compactação em níveis de tamanho compactará os quadros de tamanho semelhante em conjunto. Os dados tendem a se mover para sstables maiores à medida que envelhecem, então a lápide (em um novo, pequeno sstable) é improvável de ser compactada com os dados (em um velho, grande sstable).
• A Estratégia de compactação nivelada é dividida em muitos níveis que são compactados separadamente. A lápide será escrita no nível 0 e irá efetivamente ‘perseguir’ os dados através dos níveis – ele deve, eventualmente, recuperar.
• A Estratégia de compactação da janela temporal (ou a estratégia de compactação com datas) nunca compactará a lápide com os dados se forem escritos em diferentes janelas de tempo.quando é que as lápides causam problemas?
  

  Utilização do disco

  quando os dados são apagados, o espaço não será de facto libertado pelo menos durante o período gc_ Grace definido na configuração da tabela. Isso pode causar problemas se um aglomerado está se enchendo rapidamente.em algumas circunstâncias, o espaço nunca será libertado sem intervenção manual.

  read performance

  graves performance problems can occur if reads encounter large numbers of tombstones.

  problemas de desempenho são mais prováveis de acontecer com os seguintes tipos de consulta:

  • consultas que correm sobre todas as partições em uma tabela (“selecione * do espaço de chaves.table”)
  • Range queries (“select * from keyspace.table WHERE value > x”, or “WHERE value IN (value1, value2,…) “
  • qualquer consulta que só possa ser executada com uma cláusula de “permitir filtragem”.

  estas questões de desempenho ocorrem devido ao comportamento de lápides durante a leitura. Em uma consulta de intervalo, seu driver Cassandra normalmente usa paging, o que permite que nós retornem um número limitado de respostas de cada vez. Quando cassandra tombstones estão envolvidos, o nó precisa manter as lápides que encontrou na memória e devolvê-las ao coordenador, no caso de uma das outras réplicas não saber que os dados relevantes foram apagados. As lápides não podem ser pagadas porque é essencial devolver todas elas, de modo que a latência e o uso da memória aumentam proporcionalmente ao número de lápides encontradas.

  Se as lápides serão encontradas depende da forma como os dados são armazenados e recuperados. Por exemplo, se o Cassandra é usada para armazenar dados em uma fila (o que não é recomendado), as consultas podem encontrar dezenas de milhares de lápides para retornar algumas linhas de dados.como posso diagnosticar problemas relacionados com lápides?

  consultas que encontram um grande número de lápides irão aparecer nos logs. Por padrão, uma leitura encontrando mais de mil lápides irá gerar um aviso:

  WARN org.Apache.cassandra.PO.ReadCommand Read 0 linhas ao vivo e 87051 células tombstone para consulta SELECT * de exemplo.table

  por padrão, encontrar mais de 100.000 lápides fará com que a consulta falhe com um TombstoneOverwhelmingException.

  para verificar se as leituras de lápide estão a causar problemas de desempenho, Verifique se as leituras estão correlacionadas com um aumento na latência de leitura e na duração da pausa de GC.

  Se é evidente que as lápides são os problemas, as técnicas a seguir podem ajudar a reduzir o escopo do problema:

  • O número de marcas para exclusão retornados em uma consulta pode ser encontrado ao executar a consulta no cqlsh com rastreio activado.
  • as estatísticas para o número de lápides encontradas recentemente em cada tabela estão disponíveis na saída de nodetool cfstats.
  • para clusters em nosso serviço gerenciado, as estatísticas para lápides encontradas recentemente estão disponíveis na página do cluster em listas métricas > Informação da tabela. Isto inclui células vivas por leitura e média e Max lápides por leitura, discriminadas por nó ou tabela para um determinado período de tempo.
  • informações mais detalhadas sobre lápides armazenadas podem ser encontradas usando IC-tools.como posso evitar problemas com lápides?

    as seguintes opções podem ajudar:

    • evite consultas que irão correr em todas as partições da tabela (por exemplo, consultas sem cláusula de onde, ou qualquer consulta que necessita de permitir a filtragem).
    • altera as consultas de gama para evitar a consulta de dados apagados, ou operar em uma gama mais estreita de dados. Problemas de desempenho só ocorrem se as lápides são lidas, e escala com o número de lápides lidas.
    • Desenhe o modelo de dados para evitar a exclusão de grandes quantidades de dados.
    • Se estiver a planear apagar todos os dados numa tabela, truncar ou largar a tabela para remover todos os dados sem gerar lápides.
    • utilize um valor predefinido do tempo de vida. Isso só funciona de forma eficiente se a chave primária de seus dados for baseada no tempo, seus dados são escritos em ordem cronológica, e os dados serão apagados em uma data conhecida. Para o efeito, defina um TTL por omissão nas opções do nível da tabela e defina uma estratégia de compactação baseada no tempo (Estratégia de compactação baseada no tempo, se disponível, estratégia de concorrência baseada nos dados, caso contrário). Isso ainda irá criar lápides, mas sstables inteiros serão eficientemente descartados uma vez que o TTL em todos os seus conteúdos tenham passado.como posso livrar-me das lápides existentes?

      na maioria das circunstâncias, a melhor abordagem é esperar que a lápide compacta normalmente. Se problemas urgentes de desempenho ou de Uso do disco requerem ação mais imediata, existem dois comandos nodetool que podem ser usados para forçar compactações, que podem ajudar na queda de lápides. Estes devem ser considerados um último recurso-em um conjunto saudável com um modelo de dados bem projetado, não é necessário executar compactações manuais.

      Running nodetool compact forces a compactation of all sstables. Isto requer uma grande quantidade de espaço livre em disco. Os argumentos do Keyspace e da tabela devem ser usados para limitar a compactação às tabelas onde as lápides são um problema. Nas tabelas onde é usada uma estratégia de compactação em níveis de tamanho, este comando pode levar à criação de um enorme sstable que nunca terá pares para compactar com; se a bandeira –split-output estiver disponível, deve ser usada.

      o comando nodetool garbagecollect está disponível a partir de Cassandra 3.10 em diante. Este comando executa uma série de compactações menores que também verificam sstables sobrepostos. É mais intensivo de CPU e demorado do que nodetool compact, mas requer menos espaço livre em disco.

      Tombstones só serão removidos se gc_grace_segundos tiverem decorrido desde que os tombstones foram criados. O objetivo pretendido do gc_grace_seconds é fornecer tempo para reparos para restaurar a consistência ao cluster, então tenha cuidado ao modificá – lo-a remoção prematura de lápides pode resultar na ressurreição de dados apagados. Além disso, a configuração gc_grace_seconds afeta a expiração das dicas geradas para o handoff sugerido, por isso é perigoso reduzir gc_grace_seconds abaixo da duração da janela de handoff sugerida (por padrão, 3 horas).

      as reparações

      as reparações podem atrasar ou impedir o lançamento de lápides. Quando uma reparação completa ou incremental é executada, os sstables que afetou são marcados como reparados; em compactações subsequentes, estas tabelas serão compactadas separadamente dos sstables que não foram reparados. Se as lápides estão em sstables não reparados e os dados sombreados estão em sstables reparados( ou vice-versa), os dados não podem ser descartados porque os sstables não podem ser compactados juntos.se você regularmente executar reparos completos ou incrementais no cluster, isso não deve ser muito de um problema, uma vez que lápides e dados acabarão por ser reparados. No entanto, se você tem uma mistura de dados reparados e não reparados, e você não está regularmente executando reparos, isso pode se tornar um problema. o sstablemetadata pode ajudá-lo a inspecionar o estado reparado dos seus sstables para determinar se isto está a acontecer. Se for, pode ser aconselhável definir todos os sstables como não emparelhados com sstablerepairedset para que eles possam ser compactados juntos.por favor, note que as reparações subrange não marcam os dados como reparados.