Performance no Netezza: distribuição, zone maps e cargas rápidas

O Netezza premia um instinto completamente diferente de um banco em linha como o PostgreSQL. Não há índices para ajustar; a performance é decidida quase inteiramente por como seus dados estão espalhados pelo appliance. Acerte a chave de distribuição e as consultas voam em paralelo por todas as data slices; erre e o appliance inteiro espera por um único nó sobrecarregado.

Um modelo mental diferente: MPP

O Netezza é um appliance de processamento massivamente paralelo (MPP). Os dados são espalhados por muitas data slices, e cada slice processa sua parte em paralelo. Isso faz com que a decisão de tuning mais importante não seja um índice — é como os dados são distribuídos entre as slices.

A chave de distribuição decide tudo

CREATE TABLE sales (
  sale_id   BIGINT,
  customer_id BIGINT,
  amount    NUMERIC(12,2)
) DISTRIBUTE ON (customer_id);

Dois modos de falha a evitar:

• Skew de dados — uma chave com poucos valores distintos (ou muitos nulos) empilha linhas em poucas slices. Essas slices viram o gargalo enquanto o resto fica ocioso. Verifique com nz_skew.
• Redistribuição no join — se duas tabelas unidas usam chaves de distribuição diferentes, o Netezza precisa redistribuir uma pela rede em tempo de consulta. Co-localize os joins distribuindo ambas as tabelas pela coluna de junção.

Escolha uma coluna de alta cardinalidade muito usada em joins. O DISTRIBUTE ON RANDOM evita skew mas força redistribuição em todo join — use só para staging.

Zone maps substituem índices

O Netezza não tem índices tradicionais. Em vez disso, os zone maps registram automaticamente o mínimo/máximo de certas colunas por extent, permitindo pular extents que não podem casar com uma faixa do WHERE — conceitualmente idêntico ao BRIN do PostgreSQL. Funcionam melhor quando os dados estão naturalmente ordenados, então carregar em ordem de data deixa consultas por faixa de data muito mais rápidas.

GROOM e estatísticas

GROOM TABLE sales;              -- recupera espaço de linhas apagadas/atualizadas
GENERATE STATISTICS ON sales;  -- mantém o otimizador honesto

Como o VACUUM do PostgreSQL, updates e deletes deixam linhas logicamente apagadas até o GROOM recuperá-las. Estatísticas desatualizadas geram planos ruins — regenere-as após cargas grandes.

Carga em massa rápida com nzload

nzload -t sales -df /data/sales.csv \
  -delim ',' -skipRows 1 -maxErrors 100 \
  -bf /data/sales.bad

Carregue numa tabela já distribuída corretamente, na ordem natural do seu filtro por faixa mais comum, e depois rode GENERATE STATISTICS. Carregar primeiro e distribuir depois desperdiça uma passada inteira de redistribuição.

A constante: observe seu skew e suas estatísticas

Seja o engine Netezza, PostgreSQL ou outro, as verdades operacionais rimam: layout de dados desigual e estatísticas velhas tornam, silenciosamente, consultas rápidas em lentas. A disciplina de monitoramento que o PG Monitoring traz ao PostgreSQL — acompanhar mudanças de plano, pegar a regressão no dia em que aparece — vale diretamente para qualquer plataforma analítica que você rode ao lado.