Atualizando uma grande dimensão replicada (SQL Server PDW)

Usamos um dispositivo SQL Server PDW para nosso armazém de dados. Uma das tabelas em nosso armazém é uma tabela replicada com cerca de 20 milhões de linhas. Como parte do nosso processo ETL, precisamos expirar registros antigos dessa dimensão; no entanto, estamos vendo que a atualização de um punhado de registros (<100) leva mais de uma hora para ser concluída. É isso que eu gostaria de melhorar, se puder.

Naturalmente, uma opção em que pensei foi mudar essa dimensão de Replicado para Distribuído. Meus testes mostram que isso resolveria o problema com o processo ETL demorando muito (de 1,5 horas a 30 segundos), mas todas as junções contra a versão Distribuída dessa dimensão seriam afetadas, pois as junções quase nunca se baseiam na mesma distribuição coluna. Quando olho para o plano de execução de algumas dessas consultas, geralmente vejo uma operação ShuffleMove ou BroadcastMove .

Portanto, minha pergunta para o guru do PDW aqui é:

Há algo mais que possa ser feito para melhorar o desempenho da atualização de registros na versão replicada desta dimensão?

Novamente, mudar para uma tabela Distribuída não parece ser a melhor solução, pois afetará centenas de consultas e relatórios SQL já escritos desenvolvidos por outras pessoas.

Algumas questões. 20 milhões de linhas não são necessariamente tão grandes.

Qual processo você está usando para executar suas atualizações e exclusões agora?

A dimensão é um ÍNDICE DE COLUMNSTORE, CLUSTERED INDEX ou HEAP?

Você está dizendo que há movimento enquanto atualiza e exclui esta tabela ou você acabou de ver movimento quando alterou a tabela de replicada para distribuída?

Se é o último que não é surpreendente. É improvável que você seja compatível com junção e agregação. Se você estiver fazendo algo para desencadear o movimento através de sua atualização / exclusão, poderíamos analisar isso - embora um exemplo concreto seja útil.

Em termos gerais, eu começaria tentando manter o ETL simples.

Use o CTAS na dimensão, selecionando apenas as linhas que você deseja manter, unir em novas linhas e use o CASE para selecionar as alterações (convertendo o UPDATE em uma transformação no CTAS). Depois de concluído, você poderá usar um par de comandos RENAME OBJECT para alternar da tabela atual para a nova tabela. Isso oferece o benefício adicional de ter uma visão histórica da sua mesa - que você pode deixar quando quiser.

Ser replicado não impede o uso do particionamento. Particione sua mesa.

Em seguida, para as linhas que você precisa excluir ou atualizar, CTAS a partição inteira em uma nova tabela, usando LEFT JOIN e COALESCE para obter os valores apropriados (ou seja, novos) para atualizações das linhas alteradas, mantendo as linhas desejadas e excluindo o aqueles que você não faz.

Por fim, a partição alterna a nova tabela com sua partição antiga.

E feito :)

Na minha experiência, o PDW não gosta de atualizações e exclusões. O CTAS e os comutadores de partição funcionam bem.

As instruções UPDATE no PDW são apenas parcialmente paralelas, em vez de totalmente paralelas, como o CTAS.

Dito isto, isso pode muito bem estar relacionado à indexação. Qual é o código real que você está executando? Você possui índices para ajudar a encontrar os registros que você está expirando? Você ainda precisa aplicar algumas das técnicas de ajuste padrão para aplicar índices não agrupados em cluster em tabelas de armazenamento de linhas. O fato de o PDW não suportar chaves primárias geralmente parece significar que as pessoas esquecem de indexar sua chave natural, portanto, não se encontre nesse barco ...