Una manera eficiente de comparar dos grandes conjuntos de datos en SQL

12

Actualmente, estoy comparando dos conjuntos de datos que contienen StoreKey/ProductKeycombinaciones únicas .

El primer conjunto de datos tiene las StoreKey/ProductKeycombinaciones únicas para las ventas entre principios de enero de 2012 y finales de mayo de 2014 (resultado = 450 mil líneas). El segundo conjunto de datos tiene StoreKey/ProductKeycombinaciones únicas , para ventas que comienzan en junio de 2014, hasta hoy (resultado = 190,000 líneas).

Estoy buscando encontrar las StoreKey/ProductKeycombinaciones que están en el segundo set, pero no en el primer set, es decir, nuevos productos vendidos a principios de junio.

Hasta ahora, volqué los dos conjuntos de datos en tablas temporales, creé índices para ambas tablas en ambas claves y utilicé la EXCEPTdeclaración para encontrar elementos únicos.

¿Cuál es la forma más eficiente de comparar conjuntos de datos tan grandes? ¿Existe una forma más eficiente de hacer este tipo de comparación grande?

— Pierre Pretorius
fuente

10

Usar EXCEPTO es, en mi opinión, el camino a seguir aquí, pero es posible que desee reconsiderar el uso de la tabla temporal. Al hacerlo, está duplicando efectivamente sus datos en la memoria, lo que lo ralentizará. Si los índices que necesita existen en las tablas de origen (como sospecho), simplemente compare los SELECCIONES apropiados:

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

— Centelleos
fuente

1

Correcto, la tabla tiene índices, pero es un índice agrupado en los dos campos obligatorios, más un campo llamado TransactionDateKey. ¿Se vería una gran diferencia si implemento: a.) Un índice agrupado en StoreKey y ProductKey b.) ¿Dos índices separados no agrupados en StoreKey y ProductKey respectivamente?

— Pierre Pretorius

1

Supongo que TransactionDateKeyes la columna utilizada para filtrar el período de tiempo. En ese caso el índice agrupado en TransactionDateKey, StoreKeyy ProductKeyes perfecto.

— Twinkles

1

Si está familiarizado con los algoritmos (complejidad Big-O), realizar esta comparación es, en el mejor de los casos, O (n log (n)). El algoritmo más eficiente clasificará ambos conjuntos de datos y luego los combinará en paralelo para encontrar claves coincidentes (o no coincidentes). La mayoría de los optimizadores RDBMS lo harán automáticamente cuando use EXCEPTo MINUS. Su plan de explicación confirmará o desconfirmará. Si ve bucles anidados, está haciendo O (n ^ 2), no tan eficiente.

— Joshua Huber
fuente

Gracias Josua No está familiarizado con la complejidad de Big-O, pero sin duda lo echará un vistazo.

— Pierre Pretorius

Enlaces para obtener más información sobre el Análisis de Complejidad, al que algunas personas se refieren coloquialmente como Big-O. No es tan difícil como podría parecer al principio. Cuando las personas dicen que una tarea se ejecutará en tiempo lineal o en tiempo polinómico, a esto se refieren. La copia de seguridad de la base de datos en general es lineal, lo que significa que el tamaño de la base de datos 2x requiere 2 veces más tiempo para la copia de seguridad. Sin embargo, ordenar un conjunto de datos no es lineal. Un archivo 2 veces más grande toma más del doble de tiempo para ordenar. bigocheatsheet.com , en el wiki en.wikipedia.org/wiki/Time_complexity menciona que el tipo de comparación más rápido posible es "tiempo linealitmico" = n log (n).

— Joshua Huber