Como otimizar a comunicação entre slots

Ao avaliar sua capacidade de comunicação, pense na quantidade de embaralhamento que é exigida pela sua consulta. Quantos bytes são passados entre os estágios? Quantos bytes são passados para cada slot? Por exemplo, uma cláusula GROUP BY passa como valores para o mesmo slot para processamento. A quantidade de dados que é embaralhada afeta diretamente a capacidade de comunicação e, consequentemente, o desempenho da consulta.

As práticas recomendadas a seguir fornecem orientação sobre o controle de comunicação entre slots.

Reduzir os dados antes de usar um JOIN

Prática recomendada: reduza a quantidade de dados processados antes de uma cláusula JOIN.

Reduza os dados o mais cedo possível na consulta, antes que ela execute um JOIN. Se você reduz dados no início do ciclo de processamento, o embaralhamento e outras operações complexas executam somente os dados necessários.

Não tratar as cláusulas WITH como instruções preparadas

Prática recomendada: use as cláusulas WITH principalmente para fins de legibilidade.

Cláusulas WITH são usadas essencialmente para legibilidade por não serem materializadas. Por exemplo, colocar todas as suas consultas em cláusulas WITH e, em seguida, executar UNION ALL é um uso indevido da cláusula WITH. Se uma consulta aparecer em mais de uma cláusula WITH, ela será executada em cada cláusula.

Evitar tabelas fragmentadas por data

Prática recomendada: não use tabelas fragmentadas por data (também chamadas de tabelas com nome de data) no lugar de tabelas particionadas por tempo.

Tabelas particionadas têm melhor desempenho do que as tabelas com nome de data. Quando você cria tabelas fragmentadas por data, o BigQuery precisa manter uma cópia do esquema e dos metadados para cada tabela com nome de data. Além disso, quando as tabelas com nome de data são usadas, pode ser necessário que o BigQuery verifique as permissões de cada tabela consultada. Essa prática também sobrecarrega a consulta e afeta o desempenho dela.

Evitar a fragmentação excessiva de tabelas

Prática recomendada: evite criar fragmentos de tabela em demasia. Se você estiver fragmentando tabelas por data, use tabelas particionadas por tempo.

A fragmentação de tabelas refere-se a dividir grandes conjuntos de dados em tabelas separadas e adicionar um sufixo a cada nome da tabela. Se você estiver fragmentando tabelas por data, use tabelas particionadas por tempo.

Devido ao baixo custo do armazenamento do BigQuery, você não precisa otimizar suas tabelas por causa do custo, como faria em um banco de dados relacional. Criar um grande número de fragmentos de tabela tem impactos de desempenho que superam os benefícios de custo.

As tabelas fragmentadas exigem que o BigQuery mantenha o esquema, os metadados e as permissões para cada fragmento. Devido à sobrecarga extra necessária para manter informações em cada fragmento, o desempenho da consulta poderá ser afetado se houver fragmentação em excesso.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Precisa de ajuda? Acesse nossa página de suporte.