Эффективный способ сравнить два больших набора данных в SQL

12

В настоящее время я сравниваю два набора данных, которые содержат уникальные StoreKey/ProductKeyкомбинации.

Первый набор данных имеет уникальные StoreKey/ProductKeyкомбинации для продаж между началом января 2012 года и концом мая 2014 года (результат = 450 тыс. Строк). Второй набор данных имеет уникальные StoreKey/ProductKeyкомбинации, продажи начинаются с июня 2014 года до сегодняшнего дня (результат = 190 тыс. Строк).

Я ищу, чтобы найти StoreKey/ProductKeyкомбинации, которые во 2-м наборе, но не в 1-м наборе - то есть новые продукты, проданные с начала июня.

До сих пор я сбрасывал два набора данных во временные таблицы, создавал индексы для обеих таблиц по обоим ключам и использовал EXCEPTинструкцию для поиска уникальных элементов.

Каков наиболее эффективный способ сравнения таких больших наборов данных? Есть ли более эффективный способ проведения такого большого сравнения?

— Пьер Преториус
источник

10

По моему мнению, использование EXCEPT - это путь, но вы можете пересмотреть использование временной таблицы. Тем самым вы эффективно дублируете свои данные в памяти, что замедляет работу. Если нужные вам индексы существуют в исходных таблицах (как я подозреваю), просто сравните соответствующие SELECTS:

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

— Twinkles
источник

1

Правильно, таблица имеет индексы, но это кластеризованный индекс для двух обязательных полей плюс поле с именем TransactionDateKey. Будет ли большая разница, если я реализую либо: a.) Кластерный индекс для StoreKey и ProductKey b.) Два отдельных некластеризованных индекса для StoreKey и ProductKey соответственно?

— Пьер Преториус

1

Я предполагаю TransactionDateKey, что столбец используется для фильтрации периода времени. В этом случае кластерный индекс TransactionDateKey, StoreKeyи ProductKeyявляется совершенным.

— Мерцает

1

Если вы знакомы с алгоритмами (сложность Big-O), лучше всего выполнить это сравнение O (n log (n)). Наиболее эффективный алгоритм сортирует оба набора данных, а затем выполняет объединенный прогон по ним параллельно, чтобы найти совпадающие (или не сопоставленные) ключи. Большинство оптимизаторов RDBMS сделают это автоматически для вас, когда вы используете EXCEPTили MINUS. Ваш план объяснения подтвердит или не подтвердит. Если вы видите вложенные циклы, вы делаете O (n ^ 2), не так эффективно.

— Джошуа Хубер
источник

Спасибо, Джосуа. Не знаком со сложностью Big-O, но обязательно взгляну на нее.

— Пьер Преториус

Ссылки, чтобы узнать больше об Анализе сложности, который некоторые люди называют «Big-O». Это не так сложно, как может показаться на первый взгляд. Когда люди говорят, что задача будет выполняться за линейное или полиномиальное время, это то, что они имеют в виду. Резервное копирование базы данных в целом является линейным, то есть резервное копирование в 2 раза превышает размер базы данных. Сортировка набора данных это не линейный, хотя. Размер файла в 2 раза больше, чем в 2 раза больше времени для сортировки. bigocheatsheet.com , в вики en.wikipedia.org/wiki/Time_complexity упоминается, что самая быстрая из возможных сортировок - "linearithmic time" = n log (n).

— Джошуа Хубер