Migrar para o armazenamento físico do BigQuery pode gerar economia, mas é preciso ficar atento aos custos de time travel e fail-safe. Mostramos como esses recursos podem inflar sua conta e apresentamos opções para evitar isso, como reduzir a janela de time travel ou voltar para o armazenamento lógico antes de excluir dados.
Migrar do armazenamento lógico para o físico no BigQuery pode reduzir drasticamente seus custos de storage — e foi exatamente o que aconteceu com muitos clientes com quem trabalhamos.
Mas, quando você soma os custos de time travel e fail-safe do BigQuery, a conta pode acabar saindo bem mais cara do que o armazenamento lógico – ou gerar um custo de storage maior do que você esperava.
Neste post, vamos falar sobre:
- As armadilhas do time travel e do fail-safe do BigQuery que inflam seus custos
- As opções para contornar essas armadilhas
As armadilhas do time travel e do fail-safe no BigQuery
O time travel do BigQuery permite acessar dados que foram alterados ou excluídos a partir de qualquer ponto no tempo dentro de uma janela específica. Por padrão, essa janela é de sete dias, mas dá para reduzi-la para até dois dias.
Já o fail-safe do BigQuery mantém os dados excluídos por mais sete dias depois da janela de time travel, para recuperação em caso de emergência (até pouco tempo atrás eram 14 dias). E, diferentemente do time travel, esse período de retenção não pode ser alterado. Para restaurar dados do fail-safe, é preciso abrir um chamado com o Google Support.
No armazenamento físico, você paga pelos custos de time travel e fail-safe pelas tarifas de armazenamento físico ativo. Já no armazenamento lógico, você não paga por nenhum dos dois.
O gráfico abaixo simula a seguinte situação:
- O armazenamento físico de longo prazo total é de 200 GiB e, em seguida, 50 GiB são excluídos;
- A janela de time travel é de sete dias, seguida por
- Um período de fail-safe de sete dias.
Veja o caso a seguir, contado em uma sessão ao vivo de perguntas e respostas sobre BigQuery que realizamos recentemente:
Um cliente excluiu uma tabela grande que estava em armazenamento físico de longo prazo, e o time travel guardou a tabela excluída para o caso de precisar restaurá-la. Após a exclusão, os dados da tabela passaram a ser cobrados como armazenamento ativo dentro do time travel e do fail-safe. Por um total de 21 dias (sete no time travel e 14 no fail-safe, na época em que ainda eram 14 dias), o cliente pagou, sem saber, a tarifa de armazenamento ativo, o que resultou em uma conta de storage muito acima do esperado.
Opção 1: ajuste as configurações de time travel do BigQuery
Por padrão, o time travel do BigQuery está configurado para sete dias e pode ser reduzido para até dois dias. Se você puder abrir mão de um pouco da resiliência dos dados, dá para reduzir essa configuração e diminuir os custos dos dados armazenados em time travel.
Por exemplo, se você tem um processo robusto de backup do BQ para outras fontes, como o GCS, reduzir o período de time travel para dois dias deve funcionar bem. Alguns dos nossos clientes configuram políticas e pipelines de auto-arquivamento para fazer backup periódico dos dados, então, em cenários como esse, faz sentido ter períodos de time travel mais curtos, já que esses dados já estão sendo copiados fora do BigQuery.
Pela nossa experiência, a maioria dos clientes não precisa dos sete dias completos de time travel, porque, mesmo reduzindo para dois dias, ainda contam com os sete dias de fail-safe por cima. Ou seja, se cortar custos é mais importante do que ter sete dias completos de histórico, reduzir o período de time travel para dois dias não deve causar grande impacto.
Outra opção: se você está prestes a excluir um grande volume de dados, pode valer a pena reduzir o período de time travel para dois dias antes da exclusão, só para diminuir temporariamente o volume de storage retido. Só não esqueça de voltar a configuração para o valor anterior depois, se precisar!
Opção 2: converta sua tabela para o armazenamento lógico do BigQuery antes de excluí-la
A outra solução é alterar o modelo de cobrança de storage do seu dataset para armazenamento lógico antes de excluir os dados, já que nesse modelo você não é cobrado por time travel nem por fail-safe.
Atenção: essa mudança só pode ser feita uma vez a cada 14 dias, ou seja, você teria que esperar 14 dias para voltar à configuração anterior. Além disso, a alteração no modelo de storage pode levar até 24 horas para entrar em vigor.
Antes de fazer a mudança, porém, vale rodar esta query para comparar seus custos com 14 dias de armazenamento lógico vs. nove dias de armazenamento físico ativo (mínimo de 2 dias de time travel + 7 dias de fail-safe).
Veja abaixo um exemplo de saída dessa query, em que "additional_costs_for_physical_storage" inclui tanto os custos de time travel quanto os de fail-safe:
dataset
logical_active_price
base_physical_price
logical_long_term_price
base_long_term_price
additional_costs_for_physical_storage
logical_storage_price
physical_storage_price
difference_in_price_if_physical_is_chosen
recommendation
warehouse
$ 0,57
$ 0,07
$ 0,00
$ 0,00
$ 62,27
$ 0,57
$ 62,34
$ -61,77
Mantenha o dataset no armazenamento lógico
Opção 3: simplesmente não migre para o armazenamento físico do BigQuery
Se você adiciona e exclui dados o tempo todo, é bem provável que seus volumes de time travel e fail-safe sejam altos. Nesse caso, talvez nem faça sentido migrar para o armazenamento físico.
Isso porque, no modelo de armazenamento lógico, você não é cobrado pelos dados de time travel e fail-safe — mas é cobrado no modelo físico.
Então, se você tem grandes volumes de dados nessas áreas, isso pode inflar os custos para além do que o armazenamento lógico cobraria. É importante analisar esses volumes específicos ao avaliar a migração para o armazenamento físico.
A query compartilhada acima percorre um projeto (e uma única região), examinando cada um dos datasets para apresentar um detalhamento de custos e uma recomendação.
Faz sentido migrar para o armazenamento físico do BigQuery nos seguintes cenários:
- A maior parte dos seus dados é texto/strings (por exemplo, json, endereços, logs etc.), já que esses tipos têm as maiores taxas de compressão.
- Quando há um plano sólido de ciclo de vida dos dados (por exemplo, uma tabela particionada por dia, com cada partição expirando após X dias).
- Os dados não são modificados constantemente nas tabelas/partições (como mencionado acima, isso aumenta o storage de time travel e fail-safe).
Considerações finais
Em muitos casos, migrar do armazenamento lógico para o físico no BigQuery realmente reduz os custos de storage. Mesmo assim, vale a pena conhecer as armadilhas que podem anular essa economia.