Eine effiziente Möglichkeit, zwei große Datensätze in SQL zu vergleichen

12

Derzeit vergleiche ich zwei Datensätze, die eindeutige StoreKey/ProductKeyKombinationen enthalten .

Der 1. Datensatz enthält die eindeutigen StoreKey/ProductKeyKombinationen für Verkäufe zwischen Anfang Januar 2012 und Ende Mai 2014 (Ergebnis = 450.000 Zeilen). Der 2. Datensatz enthält die eindeutigen StoreKey/ProductKeyKombinationen für den Verkauf ab Juni 2014 bis heute (Ergebnis = 190.000 Zeilen).

Ich suche die StoreKey/ProductKeyKombinationen, die im 2. Satz enthalten sind, aber nicht im 1. Satz - dh neue Produkte, die ab Anfang Juni verkauft werden.

Bisher habe ich die beiden Datensätze in temporären Tabellen abgelegt, für beide Tabellen Indizes für beide Schlüssel erstellt und mithilfe der EXCEPTAnweisung nach eindeutigen Elementen gesucht.

Wie lassen sich so große Datenmengen am effizientesten vergleichen? Gibt es eine effizientere Methode für diesen großen Vergleich?

— Pierre Pretorius
quelle

10

Die Verwendung von EXCEPT ist meiner Meinung nach der richtige Weg, aber Sie können die Verwendung der temporären Tabelle überdenken. Auf diese Weise duplizieren Sie effektiv Ihre Daten im Speicher, was Sie verlangsamen wird. Wenn die Indizes, die Sie benötigen, in den Quelltabellen vorhanden sind (wie ich vermute), vergleichen Sie einfach die entsprechenden SELECTS:

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

— Funkelt
quelle

1

Richtig, die Tabelle verfügt zwar über Indizes, es handelt sich jedoch um einen Clustered-Index für die beiden erforderlichen Felder sowie ein Feld mit dem Namen TransactionDateKey. Wäre ein großer Unterschied zu sehen, wenn ich entweder implementiere: a.) Einen Clustered-Index für StoreKey und ProductKey. B.) Zwei separate, nicht-Clustered-Indizes für StoreKey bzw. ProductKey?

— Pierre Pretorius

1

Ich gehe davon aus, dass TransactionDateKeydie Spalte zum Filtern des Zeitraums verwendet wird. In diesem Fall wird der Clustered - Index auf TransactionDateKey, StoreKeyund ProductKeyist perfekt.

— Twinkles

1

Wenn Sie mit Algorithmen (Big-O-Komplexität) vertraut sind, ist die Durchführung dieses Vergleichs bestenfalls O (n log (n)). Der effizienteste Algorithmus sortiert beide Datensätze und führt sie dann parallel zusammen, um übereinstimmende (oder nicht übereinstimmende) Schlüssel zu finden. Die meisten RDBMS-Optimierer erledigen dies automatisch für Sie, wenn Sie EXCEPToder verwenden MINUS. Ihr EXPLAIN-Plan wird bestätigt oder nicht bestätigt. Wenn Sie verschachtelte Schleifen sehen, tun Sie O (n ^ 2), nicht so effizient.

— Joshua Huber
quelle

Vielen Dank, Josua. Ich kenne die Komplexität von Big-O nicht, werde sie mir aber auf jeden Fall ansehen.

— Pierre Pretorius

Links, um mehr über die Komplexitätsanalyse zu erfahren, die einige Leute umgangssprachlich als Big-O bezeichnen. Es ist nicht so schwer, wie es zuerst aussehen mag. Wenn Leute sagen, dass eine Aufgabe in linearer Zeit oder in Polynomialzeit ausgeführt wird, beziehen sie sich auf diese. Die Datenbanksicherung ist im Allgemeinen linear, was bedeutet, dass die Sicherung der doppelten Datenbankgröße zweimal so lange dauert. Sortieren eines Datensatzes ist jedoch nicht linear. Eine 2x so große Datei benötigt mehr als 2x Zeit zum Sortieren. bigocheatsheet.com , Im wiki en.wikipedia.org/wiki/Time_complexity wird erwähnt, dass die schnellstmögliche Vergleichssortierung "linearithmische Zeit" = n log (n) ist.

— Joshua Huber