SQL Server присоединиться или поиск Pentaho Spoon?

Question

Что обеспечивает более высокую производительность?

1. Написание запроса с использованием T-SQL, объединение таблиц и вставка результата в другую таблицу.

2. Использование вставки таблицы Pentaho Spoon, затем поиск по базе данных для "объединения" каждой таблицы за раз, затем вставка результата в другую таблицу

Цель состоит в том, чтобы взять денормализованную таблицу, соединить ее с 5 таблицами измерений по их тексту, извлечь PK измерений и затем вставить результат в таблицу фактов.

Answer 1

Вероятно, лучше подходит для dba.stackexchange.com. Но я предполагаю, что механизм базы данных будет выполнять эту задачу намного быстрее, потому что а) он может оптимизировать доступ ко всем задействованным таблицам, используя индексы и статистику таблиц, и б) вы избавляетесь от накладных расходов с помощью инструмента ETL и вводите несколько запросов к базе данных. Pentaho PDI обрабатывает строки индивидуально, поэтому для каждой строки, поступающей с шага ввода таблицы, у вас будет SQL-запрос для каждого шага поиска.

Answer 2

Общепринято думать, что SQL превосходит Pentaho PDI по сложным запросам. Истина исходит от слепых, которые считают, что оптимизатор SQL дает реальный оптимум.

У меня есть несколько встречных примеров, в которых мы сократили время запроса с более чем одного часа до нескольких минут, выделив сложность SQL-запроса из серии поисков и фильтров.

Мы были лучше, потому что:

1. Для поиска требуется одна совпадающая запись на запись, а оптимизатор SQL должен исходить из предположения, что соединение не уникально. И это случай развертывания схемы звезда / снежинка, как здесь.

2. Этап поиска очень умный, он читает только необходимые данные и хранит их в памяти, предоставляя внутренние отсортированные хеш-таблицы для ускорения предстоящих запросов.

3. Вышеуказанное особенно эффективно, когда известно, что поток отсортирован. И пока select from oneTable order by быстро, особенно когда таблица соответствующим образом проиндексирована, то же самое select from manyJoinedTables where LotsOfConditions order by может быть довольно неэффективным, потому что SQL не может рассчитывать на индексы.

На самом деле, я предполагаю, что приведенные выше условия являются именно теми, которые оптимизатор SQL желает найти и использовать, но не может из-за общности.

Как правило, будьте уверены в эффективности PDI. Мэтт Кастерс и Дженс Блюэль сделали очень хорошее программное обеспечение, которое было протестировано в условиях громкости, которые вы даже не можете себе представить.

Так что используйте решение, которое проще в обслуживании (чаще всего время поиска PDI), и если оно действительно очень медленное, то перенесите его в Input Tableс, но не ожидайте, что будет систематически лучше.

Заметки:

• Избегайте Database Lookup (подготовленный оператор использует кеш, но мы как раз и ищем разные ключи каждый раз).

• избежать Joins, то есть: явно сказать чайнику, что он может рассчитывать на уникальное совпадение, если вы знаете, что это так. Join Rows а также Merge Join являются эффективными шагами, но только тогда, когда входящие потоки отсортированы.

• использование Filters (уменьшить количество строк) как можно скорее. Даже каждое правило имеет свое исключение в SQL.

• Не беспокойтесь, чтобы уменьшить количество столбцов с Select values, Это практически не влияет на скорость! Вам не кажется, что Kettle наивно переписывает значения шаг за шагом, вместо того, чтобы использовать умную систему указателей, не так ли?

• Расчеты с JavaScript не так неэффективно, как гласит легенда, и на самом деле PDI обычно гораздо больше заняты сортировкой и поиском.

• Не распространяйте агрегаты во многих Memory Group by шаги. Каждый из этих шагов должен прочитать весь входящий поток, прежде чем узнать, что он завершен, поэтому он является блокирующим фактором для следующих шагов.

• Обычно Sorted Group by не улучшает Memory Group by, Единственное исключение - когда память достигает своей квоты и java начинает запускать сборщик мусора поверх сборщика мусора. В этом случае сортировка может использоваться для хранения данных на временном диске.

• Избегайте промежуточных таблиц. Вместо этого создайте поток, добавив столбцы, и когда данные будут готовы, добавьте их в Output Table с большим размером коммита.