Resumo

  • Uma tabela permanente da Snowflake passa por sete dias de Fail-safe depois do Time Travel. O prazo é fixo e os dados históricos continuam gerando cobrança de armazenamento.
  • Reduzir a retenção, escolher tabelas transient e retirar clones resolve partes diferentes da permanência dos dados. O custo acompanha os bytes retidos, inclusive de tabelas excluídas.

A tabela foi embora; a reserva de armazenamento ficou. Na Snowflake, excluir uma tabela permanente pode encerrar o trabalho do desenvolvedor antes de encerrar a cobrança dos dados. O histórico passa pelo Time Travel e depois por sete dias de Fail-safe.

Esse intervalo compra uma chance adicional de recuperação. Também conserva espaço pago quando o objeto já saiu do uso cotidiano. Para uma empresa que aprovou um projeto de redução de custos, contar exclusões entrega apenas parte da resposta. O dinheiro depende de quando os bytes deixam de ser mantidos.

A explicação dos custos de armazenamento inclui dados ativos, histórico do Time Travel, Fail-safe e dados ainda referenciados por clones. As tabelas são comprimidas, e o tamanho após a compressão entra no cálculo. Uma lista menor de tabelas pode conviver com armazenamento que ainda percorre as etapas de proteção.

A recuperação muda de mãos

No Fail-safe, o prazo de sete dias não pode ser configurado. Ele começa quando termina a retenção do Time Travel. O cliente perde o acesso normal ao histórico e passa a depender do suporte da Snowflake para uma tentativa de recuperação.

O serviço funciona na base do melhor esforço, para falhas operacionais graves e depois de tentadas as outras opções. Recuperar os dados pode levar de horas a dias. A operação usa ainda computação sem servidor sujeita a cobrança. Manter o material disponível para uma tentativa e executar essa tentativa são despesas distintas.

A proteção pode valer muito para um conjunto de dados difícil de reconstruir. Seu custo aparece antes de qualquer emergência, porque a possibilidade de resgate exige que os bytes continuem guardados. O período de recuperação faz parte da economia da tabela desde a sua criação.

O quadro oficial de armazenamento histórico apresenta as opções básicas:

Tipo de tabela Time Travel Fail-safe depois
Permanente, Standard Edition Zero ou um dia Sete dias
Permanente, Enterprise Edition e superiores De zero a 90 dias Sete dias
transient Zero ou um dia Nenhum
temporary Zero ou um dia, até a exclusão ou o fim da sessão Nenhum

Na tabela permanente, zerar o Time Travel deixa a etapa seguinte em vigor. Uma consulta histórica longa pode atrasar a entrada no Fail-safe até terminar. Processos em segundo plano também fazem a transição. O prazo descreve a sequência de proteção; liberar os dados exige que o ciclo e suas referências cheguem ao fim.

A mudança de prazo tem uma data de corte

A documentação do Time Travel mostra o que acontece quando uma tabela passa de dez dias para um. O histórico do último dia permanece acessível no Time Travel. Os dados dos dias dois a dez seguem para o Fail-safe. O acesso direto fica mais curto, enquanto o histórico antigo continua sua etapa de conservação.

Uma alteração no esquema pode chegar tarde para uma tabela já excluída. No exemplo publicado, a tabela herdou 90 dias do esquema e depois foi apagada. Reduzir o prazo do esquema para um dia preserva os 90 dias do objeto que já saiu. Para mudar a retenção desse objeto, a Snowflake orienta restaurá-lo e então alterar o seu prazo.

O administrador da conta também pode impor uma retenção mínima. Assim, o período efetivo depende das regras superiores e herdadas, além do valor local. O zero que aparece numa configuração precisa ser entendido dentro dessa política.

É uma decisão de compra feita com antecedência. Quem encerra o projeto pode receber condições de armazenamento que outra pessoa definiu quando a tabela nasceu. Alterar a regra para os objetos ainda ativos não reescreve automaticamente a história das exclusões anteriores.

O clone tem vida própria

As considerações de armazenamento descrevem o clone de cópia zero compartilhando as micropartições existentes no momento da criação. Alterações posteriores geram novas partições próprias. Cada objeto segue seu ciclo, e uma cópia de desenvolvimento pode continuar referenciando dados que a tabela original deixou de usar.

A vista TABLE_STORAGE_METRICS separa bytes ativos, de Time Travel, de Fail-safe e retidos para clones. Essa última categoria inclui também dados mantidos por backups WORM. Retirar apenas a tabela original pode deixar referências ainda necessárias a essas cópias.

Tabelas excluídas aparecem na vista enquanto geram custos de armazenamento. Recriar o mesmo nome pode deixar várias versões, cada uma com sua história. A explicação da conta passa pelos identificadores dos objetos e pelos bytes de cada versão, além do nome conhecido pelos usuários.

Os dados de Account Usage podem levar até 90 minutos para refletir uma mudança. Uma linha antiga com os quatro contadores principais zerados não gera tarifa de armazenamento. Calcular o custo restante de uma conta exige seus bytes comprimidos retidos, a retenção efetiva e a tarifa aplicável.

Um dia de histórico não é um dia de tabela

A tabela transient elimina Fail-safe e admite até um dia de Time Travel. A cobrança do seu conteúdo ativo continua enquanto ela existir. O limite de um dia vale para a proteção histórica adicional; uma tabela mantida durante semanas ocupa armazenamento ativo durante essas semanas.

Dados de trabalho reproduzíveis podem aproveitar essa escolha. Depois que o histórico expira, a Snowflake não dispõe do Fail-safe para recuperá-los. O custo migra para a reconstrução: tempo, processamento e possível interrupção do trabalho. Para dados caros de refazer, a proteção adicional pode sair mais barata.

Tabelas temporary acrescentam a duração da sessão. Seu histórico termina ao excluir a tabela ou encerrar a sessão. Desconectar o cliente não encerra a sessão por si só. O fechamento de uma janela pode, assim, deixar por fazer a limpeza que o usuário imaginava concluída.

São escolhas reais de custo e recuperação. A Snowflake define uma parte do calendário, e o cliente decide tipos de tabela, retenção e cópias. A economia chega quando os bytes cobrados saem de cena; o comando de exclusão já pode ter terminado o expediente.