Compreensão do custo de tabelas dinâmicas¶
Este tópico fornece uma visão geral dos custos de computação e armazenamento associados a tabelas dinâmicas. Para obter informações gerais sobre os custos do Snowflake, consulte Compreensão do custo total.
Custo de computação¶
Há dois custos de computação associados a tabelas dinâmicas: warehouses virtuais e computação de serviços de nuvem.
Tabelas dinâmicas requerem warehouses virtuais para atualizar – ou seja, executar consultas em objetos base quando eles são inicializados e atualizados, incluindo atualizações agendadas e manuais. Essas operações usam recursos de computação, que consomem créditos.
As tabelas dinâmicas também requerem computação de serviços de nuvem para identificar alterações em objetos base subjacentes e se o warehouse virtual precisa ser invocado. Se nenhuma alteração for identificada, os créditos do warehouse virtual não serão consumidos, pois não há novos dados para atualizar. Observe que pode haver casos em que alterações em objetos base sejam filtradas na consulta de tabela dinâmica. Nesses cenários, os créditos do warehouse virtual são consumidos porque a tabela dinâmica passa por uma atualização para determinar se as alterações são aplicáveis.
Se o warehouse virtual associado for suspenso e nenhuma alteração nos objetos base for identificada, o warehouse virtual suspenso não será invocado e nenhum crédito será consumido. Por outro lado, se forem detectadas alterações, o warehouse virtual será retomado para processar as atualizações.
As atualizações da tabela dinâmica são orientadas pelo atraso de destino configurado. Pipelines de tabela dinâmica com menor atraso de destino são atualizados com mais frequência e, portanto, incorrem em custos de computação mais altos.
Você pode usar a aba Refresh History no Snowsight para verificar se os créditos do warehouse virtual foram consumidos:
No menu de navegação, selecione Monitoring » Dynamic Tables.
Selecione sua tabela dinâmica e vá para a aba Refresh History. Marque caixa de seleção Warehouse used only para visualizar as atualizações que usaram o warehouse para atualizar.
Dica
Para obter uma compreensão clara dos custos relacionados aos seus pipelines de tabelas dinâmicas, a Snowflake recomenda testar tabelas dinâmicas usando warehouses dedicados para que o consumo do warehouse virtual atribuído às tabelas dinâmicas possa ser isolado. Você pode mover suas tabelas dinâmicas para um warehouse compartilhado depois de estabelecer uma linha de base de custo.
Custo de armazenamento¶
Tabelas dinâmicas requerem armazenamento para depositar os resultados materializados. De maneira semelhante às tabelas comuns, você pode incorrer em custos adicionais de armazenamento para Time Travel, armazenamento fail-safe e recurso de clonagem.
Esta seção discute as seguintes considerações de armazenamento para tabelas dinâmicas:
Para obter informações detalhadas sobre como esse armazenamento incorre em custos, consulte Explicação do custo de armazenamento e Considerações sobre armazenamento de dados.
Custos de Time Travel e fail-safe¶
O Snowflake Time Travel permite que você acesse e consulte o histórico de versões de tabelas dinâmicas em pontos específicos no tempo, o que pode ajudar a obter insights sobre tendências históricas, mudanças e anomalias em seus dados. Observe que as atualizações frequentes podem aumentar o acúmulo de dados de Time Travel, o que aumenta o uso total de armazenamento. Para obter mais informações, consulte Compreensão e uso do Time Travel.
Os recursos fail-safe ajudam a proteger suas tabelas dinâmicas contra perda ou corrupção de dados. Com base no período de fail-safe configurado, cobranças adicionais de armazenamento podem ser aplicadas.
Replicação de tabelas dinâmicas¶
As tabelas dinâmicas oferecem suporte à replicação entre contas e regiões, permitindo que você copie dados de um banco de dados primário para um banco de dados secundário para recuperação de desastres ou compartilhamento de dados. Isso pode servir como uma estratégia de preparação de failover para recuperação de desastres ou como um meio de compartilhar dados entre implantações para fins somente leitura. O uso de replicação com tabelas dinâmicas está sujeito a custos de replicação. Para obter mais informações, consulte Replicação e tabelas dinâmicas.
Tabelas dinâmicas suspensas¶
As tabelas dinâmicas suspensas não geram custos adicionais além das taxas de armazenamento padrão e não consomem recursos de computação. Se houver tarefas de manutenção em andamento ou trabalhos agendados que interajam com uma tabela suspensa, os recursos de computação poderão ser consumidos.
Tabelas dinâmicas transitórias¶
Snowflake oferece suporte a tabelas dinâmicas transitórias, semelhantes às tabelas regulares, que persistem até serem explicitamente removidas e estão disponíveis para todos os usuários com os privilégios adequados, sem um período fail-safe. Tabelas dinâmicas transitórias são mais bem utilizadas para dados transitórios que não precisam do mesmo nível de proteção e recuperação de dados fornecido por tabelas permanentes, ajudando a economizar em custos de armazenamento para armazenamento à prova de falhas.
Armazenamento adicional para operações de atualização incremental¶
Para operações de atualização incremental, as tabelas dinâmicas mantêm uma coluna de metadados interna adicional para identificar cada linha dentro da tabela. Os identificadores de linha internos consomem uma quantidade constante de armazenamento por linha e aumentam o custo de armazenamento de forma linear ao número de linhas na tabela (independentemente do número de colunas). Para tabelas com poucas colunas, o aumento no armazenamento em comparação com uma tabela CTAS equivalente pode ser significativo, ou até mesmo dominante. Em tabelas dinâmicas mais amplas, esse efeito é menos pronunciado.
Custo do cronograma de atualização¶
O cronograma no qual uma tabela dinâmica é atualizada, seja completo ou incremental, tem um efeito em seu custo total. Esta seção discute os fatores a serem considerados ao decidir sobre um cronograma de atualização (supondo que não haja atualização vazia):
Nota
As atualizações são relativamente baratas se as fontes não tiverem mudado. Para obter mais informações, consulte Custo de computação (neste tópico).
Cronograma de atualização completo¶
O custo de atualização completa normalmente depende dos dados verificados e da frequência de atualização. Para diminuir os custos, você pode atualizar suas tabelas dinâmicas somente quando necessário – por exemplo, suspender suas tabelas dinâmicas fora do horário comercial. Para um controle de tempo preciso, defina o atraso de destino downstream para suas tabelas dinâmicas e use a atualização manual de uma tarefa para automatizar os cronogramas personalizados.
Cronograma de atualização incremental¶
O custo da atualização incremental é normalmente proporcional ao volume de alterações nos objetos de origem, mais alguma sobrecarga fixa.
Se a sobrecarga for baixa, você pode definir uma frequência de atualização alta sem muitas desvantagens. Isso significa que você pode atualizar com frequência para obter melhores resultados. Por exemplo, uma simples consulta SELECT ... FROM ... WHERE em uma tabela dinâmica processa apenas as linhas alteradas entre as atualizações, o que tem uma sobrecarga mínima e pode ser executado com frequência com baixo custo adicional.
Se a sobrecarga for alta, você deve encontrar um ponto de equilíbrio entre o consumo de crédito da alta frequência de atualização e os benefícios comerciais da atualização. Por exemplo, em uma tabela dinâmica com uma junção, as alterações em uma tabela devem ser unidas às da outra tabela. Não importa quão pequeno seja o conjunto de alterações, essa junção geralmente envolve um custo mínimo para ser executada. Se essa sobrecarga for significativa, ela poderá ser acumulada à medida que a frequência de atualização aumenta.