Uma maneira eficiente de comparar dois grandes conjuntos de dados no SQL

12

Atualmente, estou comparando dois conjuntos de dados, que contêm um único StoreKey/ProductKey combinações .

O 1º conjunto de dados possui StoreKey/ProductKeycombinações exclusivas para vendas entre o início de janeiro de 2012 e o final de maio de 2014 (resultado = 450 mil linhas). O segundo conjunto de dados possui o únicoStoreKey/ProductKey combinações , para vendas iniciadas em junho de 2014, até hoje (resultado = 190 mil linhas).

Estou procurando encontrar o StoreKey/ProductKey combinações que estão no 2º set, mas não no 1º set - ou seja, novos produtos vendidos a partir do início de junho.

Até agora, eu coloquei os dois conjuntos de dados em tabelas temporárias, criei índices para ambas as tabelas nas duas chaves e usei o EXCEPT instrução para encontrar itens exclusivos.

Qual é a maneira mais eficiente de comparar conjuntos de dados tão grandes? Existe uma maneira mais eficiente de fazer esse tipo de comparação grande?

— Pierre Pretorius
fonte

10

Usar EXCEPT é, na minha opinião, o caminho a seguir aqui, mas convém reconsiderar o uso da tabela temporária. Ao fazer isso, você efetivamente está duplicando seus dados na memória, o que o tornará mais lento. Se os índices que você precisa existir nas tabelas de origem (como suspeito), basta comparar os SELECTS apropriados:

SELECT StoreKey,ProductKey FROM table WHERE sales BETWEEN date1 AND date2
EXCEPT
SELECT StoreKey,ProductKey FROM table WHERE sales BETWEEN date3 AND date4

— Twinkles
fonte

1

Correto, a tabela possui índices, mas é um índice agrupado nos dois campos obrigatórios, além de um campo chamado TransactionDateKey. Será observada uma grande diferença se eu implementar: a.) Um índice clusterizado no StoreKey e ProductKey b.) Dois índices não clusterizados separados no StoreKey e ProductKey, respectivamente?

— Pierre Pretorius

1

Suponho que TransactionDateKeyseja a coluna usada para filtrar o período. Nesse caso, o índice agrupado na TransactionDateKey, StoreKeye ProductKeyé perfeito.

— Twinkles

1

Se você estiver familiarizado com algoritmos (complexidade Big-O), realizar essa comparação é, na melhor das hipóteses, O (n log (n)). O algoritmo mais eficiente classificará os dois conjuntos de dados e fará uma mesclagem executada em paralelo para encontrar chaves correspondentes (ou sem correspondência). A maioria dos otimizadores de RDBMS fará isso automaticamente quando você estiver usando EXCEPTou MINUS. Seu plano de explicação irá confirmar ou desconfirmar. Se você vir loops aninhados, estará executando O (n ^ 2), não tão eficiente.

— Joshua Huber
fonte

Obrigado Josua. Não está familiarizado com a complexidade do Big-O, mas certamente dará uma olhada.

— Pierre Pretorius

Links para saber mais sobre a Análise de Complexidade, à qual algumas pessoas se referem coloquialmente como Big-O. Não é tão difícil quanto parece à primeira vista. Quando as pessoas dizem que uma tarefa será executada em tempo linear ou polinomial, é a isso que eles estão se referindo. O backup do banco de dados em geral é linear, o que significa que o tamanho do banco de dados 2x leva o tempo 2x para o backup. A classificação de um conjunto de dados não é linear. Um arquivo com o dobro do tamanho leva mais que o dobro do tempo para classificar. bigocheatsheet.com , no wiki en.wikipedia.org/wiki/Time_complexity , menciona que a classificação de comparação mais rápida possível é "tempo linearitmico" = n log (n).

— Joshua Huber