Un modo efficiente per confrontare due grandi set di dati in SQL

12

Attualmente sto confrontando due set di dati, che contengono StoreKey/ProductKeycombinazioni uniche .

Il primo set di dati presenta le StoreKey/ProductKeycombinazioni uniche per le vendite tra inizio gennaio 2012 e fine maggio 2014 (risultato = 450.000 righe). Il 2 ° set di dati ha le StoreKey/ProductKeycombinazioni uniche , per le vendite a partire da giugno 2014, fino ad oggi (risultato = 190 K righe).

Sto cercando di trovare le StoreKey/ProductKeycombinazioni che si trovano nel 2 ° set, ma non nel 1 ° set, ovvero nuovi prodotti venduti dall'inizio di giugno.

Fino ad ora, ho scaricato i due set di dati in tabelle temporanee, creato indici per entrambe le tabelle su entrambe le chiavi e usato l' EXCEPTistruzione per trovare elementi unici.

Qual è il modo più efficiente di confrontare set di dati così grandi? Esiste un modo più efficiente di eseguire questo tipo di confronto di grandi dimensioni?

— Pierre Pretorius
fonte

10

L'utilizzo di EXCEPT è secondo me il modo di andare qui, ma potresti voler riconsiderare l'uso della tabella temporanea. In questo modo stai duplicando efficacemente i tuoi dati in memoria, il che ti rallenterà. Se gli indici necessari sono presenti nelle tabelle di origine (come sospetto), basta confrontare i SELECTS appropriati:

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

Corretto, la tabella ha indici, ma è un indice cluster sui due campi obbligatori, oltre a un campo denominato TransactionDateKey. Sarebbe una grande differenza se implementassi: a.) Un indice cluster su StoreKey e ProductKey b.) Due indici separati non cluster su StoreKey e ProductKey rispettivamente?

— Pierre Pretorius,

1

Presumo TransactionDateKeysia la colonna utilizzata per filtrare il periodo di tempo. In tal caso il cluster indice TransactionDateKey, StoreKeyed ProductKeyè perfetta.

— Scintilla il

1

Se hai familiarità con gli algoritmi (complessità Big-O), eseguire questo confronto è nella migliore delle ipotesi O (n log (n)). L'algoritmo più efficiente ordinerà entrambi i set di dati, quindi eseguirà una fusione lungo in parallelo per trovare chiavi corrispondenti (o non corrispondenti). La maggior parte degli ottimizzatori RDBMS lo farà automaticamente per te quando stai usando EXCEPTo MINUS. Il tuo piano esplicativo confermerà o non confermerà. Se vedi loop nidificati, stai facendo O (n ^ 2), non altrettanto efficiente.

— Joshua Huber
fonte

Grazie Josua. Non ho familiarità con la complessità della Big-O, ma sicuramente la vedremo.

— Pierre Pretorius,

Collegamenti per saperne di più sull'analisi della complessità, che alcune persone chiamano colloquialmente Big-O. Non è così difficile come potrebbe sembrare all'inizio. Quando le persone dicono che un'attività verrà eseguita in tempo lineare o in tempo polinomiale, questo è ciò a cui si riferiscono. Il backup del database in generale è lineare, il che significa che la dimensione del database 2x richiede il tempo 2x per il backup. Tuttavia, l'ordinamento di un dato non lo rende lineare. Un file di dimensioni pari a 2x richiede più del doppio del tempo per ordinare. bigocheatsheet.com , Nel wiki en.wikipedia.org/wiki/Time_complexity menziona che l'ordinamento di confronto più veloce possibile è "tempo linearitmico" = n log (n).

— Joshua Huber,