Ефективний спосіб порівняння двох великих наборів даних у SQL

12

В даний час я порівнюю два набори даних, які містять унікальні StoreKey/ProductKeyкомбінації.

1-й набір даних має унікальні 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

— Мерехтіння
джерело

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. Це не так складно, як може здатися спочатку. Коли люди кажуть, що завдання буде виконуватись у лінійному або поліноміальному часі, саме так вони і мають на увазі. Резервне копіювання бази даних в цілому лінійне, тобто 2x розмір бази даних займає 2 рази для резервного копіювання. Сортування даних встановлює, що це не лінійно. Файл 2x великий займає більше 2 разів часу на сортування. bigocheatsheet.com , У wiki en.wikipedia.org/wiki/Time_complexity він згадує про найшвидший сорт порівняння: "лінійно-часовий час" = n log (n).

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