Como o modo de atualização afeta o desempenho da tabela dinâmica¶

Compreensão do desempenho de atualização incremental¶

Em uma atualização incremental, a maior parte do esforço geralmente é destinada ao cálculo de alterações na tabela dinâmica. Isso depende da consulta e pode ser bastante complexo. Um mal-entendido comum é que uma atualização incremental verifica apenas alterações nas tabelas de origem, não as tabelas de origem em si. Isso pode levar ao equívoco de que uma atualização incremental só deve fazer um trabalho proporcional à quantidade de dados de origem que foram alterados, o que não é verdade. Na realidade, as atualizações incrementais geralmente precisam verificar as tabelas de origem diretamente.

Por exemplo, imagine uma consulta que faça uma junção interna entre as tabelas A e B. Se uma linha for inserida na tabela A, ela deverá ser unida à tabela B para calcular as alterações na consulta. Essa única linha em A pode se juntar a muitas linhas em B, o que pode significar que há muito trabalho, mesmo que haja apenas algumas alterações nas fontes.

Esse trabalho extra pode acontecer com vários operadores. A atualização incremental processa novos dados e ignora o trabalho já feito. Decidir o que ignorar pode exigir trabalho adicional, especialmente para consultas complexas e diferentes operadores podem ignorar o trabalho de diferentes maneiras.

Normalmente, o tamanho das alterações e a localidade afetam a quantidade de trabalho que pode ser ignorada.

Como o tamanho afeta o desempenho da atualização incremental¶

O fator mais significativo que afeta o desempenho da atualização incremental é o tamanho das alterações nos dados de origem. Ao determinar o tamanho das alterações nas atualizações da tabela dinâmica, certifique-se de incluir as linhas copiadas na contagem. Uma DML que altere algumas linhas em uma micropartição também copia as linhas inalteradas dessa micropartição para uma nova micropartição.

Para analisar o número de linhas alteradas em uma tabela base, crie um fluxo na tabela base no momento da última atualização e use SYSTEM$STREAM_BACKLOG. Por exemplo:

CREATE STREAM mystream ON TABLE mybasetable BEFORE(STATEMENT => 'last refresh UUID');

SELECT * FROM SYSTEM$STREAM_BACKLOG('mystream');

Como exemplo extremo, considere o efeito de excluir todos os dados de uma fonte: uma atualização completa vê apenas uma tabela vazia, que pode ser processada muito rapidamente. Por outro lado, uma atualização incremental precisa processar cada linha excluída, o que a torna muito mais lenta.

Desacelerações semelhantes também podem ocorrer em casos menos extremos. Uma boa diretriz para uma carga de trabalho favorável é manter as alterações na origem ou no destino em menos de 5% das linhas.

Como a localidade afeta o desempenho da atualização incremental¶

O segundo fator que mais afeta a atualização incremental é a localidade, que se refere ao quão intimamente os dados ou ações estão relacionados em diferentes dimensões.

Por exemplo, se você tiver uma tabela com uma coluna de carimbo de data/hora e sempre inserir linhas com a hora atual nessa coluna, sua carga de trabalho terá uma forte localidade entre a ordem de inserção e a coluna de carimbo de data/hora.

A localidade pode aparecer de várias formas, mas algumas são especialmente importantes para a atualização incremental. Melhorar a localidade em qualquer uma das áreas a seguir aumenta o desempenho das atualizações incrementais, embora nem sempre seja possível ter uma localidade forte em todas as três categorias.

Expectativas de desempenho para atualizações incrementais de operadores individuais¶

A tabela a seguir mostra as expectativas de desempenho aproximadas para atualizações incrementais de operadores individuais. O desempenho é medido em relação a uma atualização completa, supondo que apenas 5% das linhas foram alteradas e que os trabalhos de atualização levam pelo menos 1 minuto.

Para operadores afetados pela localidade, a tabela mostra as expectativas de desempenho com localidade boa e ruim. Observe que, para alguns operadores, uma localidade ruim pode levar a um desempenho pior do que atualizações completas.

Para obter mais informações, consulte Como os operadores atualizam incrementalmente.

Otimização do desempenho do modo de atualização incremental para tabelas dinâmicas complexas¶

Tabelas dinâmicas geralmente contêm vários operadores, tornando mais difícil prever seu desempenho com atualizações incrementais. Esta seção explora como lidar com esse desafio e fornece algumas dicas para melhorar o desempenho de tabelas dinâmicas complexas.

Quando há vários operadores envolvidos, as atualizações incrementais calculam as alterações trabalhando em cada operador separadamente, transformando-o em um fragmento de um plano de consulta que pode calcular alterações com base em suas entradas. Para cada entrada, esse novo fragmento pode solicitar a entrada antes das alterações, depois das alterações ou apenas as alterações em si. Ao aplicar esse processo a cada operador na consulta original, você obtém um novo plano de consulta que calcula alterações usando uma combinação de verificações de alteração e verificações de tabela completas. Este plano é otimizado pelo otimizador de consultas do Snowflake e executado como qualquer outra consulta.

Quando uma atualização incremental não tem um bom desempenho, geralmente é porque há muitas alterações ou a localidade é ruim. Consultas complexas dificultam ainda mais a identificação desses problemas. O desempenho dos operadores incrementais geralmente depende da quantidade de alterações e da localidade de suas entradas. No entanto, essas entradas são as saídas de outros operadores, portanto, a quantidade e a localidade dos dados podem mudar à medida que eles passam pelos operadores.

Portanto, entender o desempenho de uma atualização incremental complexa requer considerar a entrada de cada operador separadamente. Aqui estão alguns cenários comuns e sugestões para lidar com eles: