Cassandra: manutenção

Sou inexperiente com Cassandra, mas tenho alguma experiência com bancos de dados relacionais baseados em SQL.

Não consegui encontrar informações sobre as melhores práticas sobre como manter o Cassandra uma vez implantado. É necessário aspirar o banco de dados? Eu acho que as cargas de leitura / gravação causam fragmentação no armazenamento.

Ou, de maneira mais geral: quais são as melhores práticas para manter uma implantação de produção do Cassandra? O que tem que ser feito em intervalos regulares para manter a saúde do sistema? O manual de operações realmente não discute esse aspecto.

Obrigado.

Em geral, um cluster bem projetado pode viver por ANOS sem ser tocado. Eu tive clusters que funcionavam há anos sem interrupção. No entanto, aqui estão algumas diretrizes:

O monitoramento é extremamente importante:

1) Monitorar latências. Use o opscenter ou suas ferramentas de métricas favoritas para acompanhar as latências. As latências em ascensão podem ser sinais de problemas, incluindo pausas no GC (mais comuns em cargas de trabalho de leitura do que cargas de trabalho de gravação), problemas estáveis ​​e similares.

2) Monitore contagens estáveis. As contagens de SSTable aumentarão se você exceder a compactação (cada sstable é gravado exatamente uma vez - as exclusões são tratadas combinando sstables antigos em novos sstables por meio da compactação).

3) Monitore as alterações de estado do nó (para cima / para baixo, etc). Se você vir nós batendo, investigue, pois isso não é normal.

4) Acompanhe o uso do seu disco - tradicionalmente, você precisa ficar abaixo de 50% (especialmente se você usar a compactação STCS).

Existem algumas coisas básicas que você deve e não deve fazer regularmente:

1) Não execute explicitamente nodetool compact. Você mencionou que fez isso, não é fatal, mas cria sstables muito grandes, que são menos propensos a participar da compactação no futuro. Você não precisa necessariamente continuar executando, mas às vezes pode ajudar a se livrar dos dados excluídos / substituídos.

2) nodetool repairé normalmente recomendado a cada gc_grace_seconds10 dias, por padrão. Existem cargas de trabalho em que isso é menos importante - a maior razão pela qual você PRECISA reparar é garantir que os marcadores de exclusão ( tombstones) sejam transmitidos antes de expirarem (eles permanecem vivos gc_grace_seconds, se um nó estiver inativo quando a exclusão aconteceu, esses dados poderão voltar à vida útil) sem o reparo!). Se você não emitir exclusões e consultar com nível de consistência suficiente (leituras e gravações no QUORUM, por exemplo), poderá realmente viver uma vida sem reparo.

3) Se você for reparar, considere o uso de reparo incremental e repare pequenos intervalos de cada vez.

4) Estratégias de compactação são importantes - muito. O STCS é ótimo para gravações, o LCS é ótimo para leituras. O DTCS tem algumas peculiaridades.

5) Os modelos de dados são importantes - assim como os ambientes RDBMS / SQL enfrentam problemas quando consultas não indexadas atingem tabelas grandes, o Cassandra pode ser problemático com linhas / partições muito grandes.

6) Instantâneos são baratos. Muito barato. Quase instantaneamente, apenas links físicos, eles custam quase nenhum espaço em disco imediatamente. Use o instantâneo antes de atualizar as versões, especialmente as principais.

7) Tenha cuidado com exclusões. Como sugerido no item 2, delete cria mais dados no disco e não o libera pelo menos gc_grace_seconds.

Quando tudo falha:

Vi artigos que sugerem que o Cassandra in prod requer um chefe dedicado para gerenciar qualquer cluster de tamanho - não sei se é necessariamente verdade, mas se você estiver preocupado, convém contratar um consultor de terceiros (TheLastPickle, Pythian ) ou tenha um contrato de suporte (Datastax) para lhe dar um pouco de tranquilidade.

De acordo com a documentação de reparo do Cassandra , nodetool repairdeve ser executado nas seguintes situações:

• Como prática recomendada, você deve agendar reparos semanalmente. Nota: Se nunca houver exclusões, você ainda deverá agendar reparos regulares. Lembre-se de que definir uma coluna como nula é uma exclusão.
• Durante a recuperação do nó. Por exemplo, ao trazer um nó de volta ao cluster após uma falha.
• Em nós que contêm dados que não são lidos com frequência.
• Para atualizar dados em um nó que esteve inativo.

Eu acho que as cargas de leitura / gravação causam fragmentação no armazenamento.

Os dados no Cassandra não "fragmentam" da maneira que você está pensando. No entanto, as exclusões acionam o posicionamento de lápides e o processo compacto normal elimina as lápides.

Agora eu entendo que a compactação é muito importante e é executada automaticamente

Corrigir. Foi-me dito por um representante do DataStax que, uma vez executado compactmanualmente, você sempre precisará executá-lo manualmente. O motivo é que a compactação funciona "compactando" todos os SSTABLES existentes em um espaço de chave em um único arquivo SSTABLE. Você pode ter algumas famílias de colunas nesse arquivo SSTABLE pequenas e que demoram tanto para aumentar além do limite de compactação, que a probabilidade de compactação automática em execução novamente é muito baixa.

Essencialmente, certifique-se de agendar uma nodetool repairoperação regular , nunca executar nodetool compacte implementar uma estratégia de backup (instantâneos, backups incrementais ou ambos).