Prática recomendada: evite autojunções. Em vez disso, use uma função de janela (analítica).

Normalmente, autojunções são usadas para calcular relacionamentos dependentes de linha. O resultado de usar uma autojunção é que ela potencialmente eleva ao quadrado o número de linhas de saída. Esse aumento nos dados de saída pode causar baixo desempenho.

Em vez de usar uma junção automática, use uma função de janela (analítica) para reduzir o número de bytes adicionais gerados pela consulta.

Distorção de dados

Prática recomendada: se sua consulta processar chaves muito distorcidas para alguns valores, filtre seus dados o mais cedo possível.

A distorção de partição, às vezes chamada de distorção de dados, ocorre quando os dados são particionados em partições de tamanho muito desigual. Isso cria um desequilíbrio na quantidade de dados enviados entre os slots. Você não pode compartilhar partições entre slots, portanto, se uma partição for especialmente grande, ela pode diminuir a velocidade ou até travar o slot que processa a partição superdimensionada.

As partições se tornam grandes quando sua chave de partição tem um valor que ocorre com mais frequência do que qualquer outro valor. Por exemplo, agrupar por um campo user_id onde há muitas entradas para convidado ou NULL.

Quando os recursos de um slot estão sobrecarregados, ocorre um erro de recursos excedidos. Atingir o limite de shuffle para um slot (2 TB na memória compactada) também faz com que o shuffle grave no disco e afete ainda mais o desempenho. Os clientes com preços fixos podem aumentar o número de slots alocados.

Se você examinar o plano de explicação da consulta e observar uma diferença significativa entre os tempos médio e máximo de computação, provavelmente seus dados estão distorcidos.

Para evitar problemas de desempenho resultantes da distorção de dados:

Use uma função de agregação aproximada, como APPROX_TOP_COUNT, para determinar se os dados estão distorcidos.

Filtre seus dados o mais cedo possível.

junções desbalanceadas

A distorção de dados também pode aparecer quando você usa cláusulas JOIN. Como o BigQuery embaralha os dados em cada lado da junção, todos os dados com a mesma chave de junção vão para o mesmo estilhaço. Esse embaralhamento pode sobrecarregar o slot.

Para evitar problemas de desempenho associados a uniões não balanceadas:

Pré-filtre as linhas da tabela com a chave não balanceada.

Se possível, divida a consulta em duas consultas.

Use a instrução SELECT DISTINCT ao especificar uma subconsulta na cláusula WHERE, para avaliar valores de campo exclusivos apenas uma vez.

Por exemplo, em vez de usar a seguinte cláusula que contém uma instrução SELECT:

table1.my_id NOT IN (

. SELECT my_id

. DA tabela2

. )

Em vez disso, use uma cláusula que contenha uma instrução SELECT DISTINCT:

table1.my_id NOT IN (

. SELECT DISTINCT my_id

. DA tabela2

. )

Junções transversais (produto cartesiano)

Prática recomendada: evite junções que geram mais saídas do que entradas. Quando um CROSS JOIN for necessário, pré-agregue seus dados.

Junções cruzadas são consultas em que cada linha da primeira tabela é unida a todas as linhas da segunda tabela (existem chaves não exclusivas em ambos os lados). A saída do pior caso é o número de linhas na tabela à esquerda multiplicado pelo número de linhas na tabela à direita. Em casos extremos, a consulta pode não ser concluída.

Se o trabalho de consulta for concluído, a explicação do plano de consulta mostrará linhas de saída versus linhas de entrada. Você pode confirmar um produto cartesiano modificando a consulta para imprimir o número de linhas em cada lado da cláusula JOIN, agrupadas pela chave de junção.

Para evitar problemas de desempenho associados a junções que geram mais saídas do que entradas:

Use uma cláusula GROUP BY para pré-agregar os dados.

Use uma função de janela. As funções de janela geralmente são mais eficientes do que usar uma junção cruzada. Para obter mais informações, consulte as funções da janela.

Instruções DML que atualizam ou inserem linhas únicas

Prática recomendada: evite instruções DML específicas de ponto (atualizando ou inserindo 1 linha por vez). Agrupe suas atualizações e inserções.

O uso de instruções DML específicas de ponto é uma tentativa de tratar o BigQuery como um sistema de processamento de transações on-line (OLTP). O BigQuery se concentra no processamento analítico on-line (OLAP) usando verificações de tabela e não pesquisas de ponto. Se você precisar de comportamento semelhante ao OLTP (atualizações ou inserções de linha única), considere um banco de dados projetado para oferecer suporte a casos de uso de OLTP, como Cloud SQL.

As instruções DML do BigQuery destinam-se a atualizações em massa. As instruções UPDATE e DELETE DML no BigQuery são orientadas para regravações periódicas de seus dados, não para mutações de linha única. A instrução INSERT DML deve ser usada com moderação. As inserções consomem as mesmas cotas de modificação que as tarefas de carregamento. Se o seu caso de uso envolver inserções frequentes de uma única linha, considere a possibilidade de transmitir seus dados.

Se agrupar suas instruções UPDATE resultar em muitas tuplas em consultas muito longas, você pode se aproximar do limite de comprimento de consulta de 256 KB. Para contornar o limite de comprimento da consulta, considere se suas atualizações podem ser manipuladas com base em critérios lógicos em vez de uma série de substituições de tuplas diretas.

Por exemplo, você pode carregar seu conjunto de registros de substituição em outra tabela e, em seguida, escrever a instrução DML para atualizar todos os valores na tabela original se as colunas não atualizadas corresponderem. Por exemplo, se os dados originais estiverem na tabela t e as atualizações forem preparadas na tabela u, a consulta terá a seguinte aparência:

ATUALIZAR

. dataset.tt

DEFINIR

. minha_coluna = u.minha_coluna

DE

. dataset.uu

ONDE

. t.my_key = u.my_key