Каковы различия между преобразованиями Merge Join и Lookup в SSIS?

Question

Привет, я новичок в пакетах служб SSIS, пишу пакет и одновременно читаю о них.

Мне нужно преобразовать DTS в пакет служб SSIS, и мне нужно выполнить объединение двух источников из разных баз данных, и мне было интересно, как лучше подходить для поиска или объединения слиянием?

На поверхности они кажутся очень похожими.«Объединение слиянием» требует предварительной сортировки данных, тогда как «Поиск» этого не требует.Любой совет будет очень полезным.Спасибо.

Answer 1

Снимок экрана # 1 показывает несколько точек, чтобы различать Merge Join transformation и Lookup transformation.

Относительно поиска:

Если вы хотите найти совпадающие строки в источнике 2 на основе входных данных источника 1 и если вы знаете, что для каждой входной строки будет только одно совпадение, то я бы предложил использовать операцию поиска. В качестве примера можно привести таблицу OrderDetails, в которой вы хотите найти совпадающие Order Id и Customer Number, тогда лучшим вариантом будет поиск.

Относительно объединения Регистрация:

Если вы хотите выполнить объединения, такие как выборка всех адресов (дома, на работе, в другом месте) из таблицы Address для данного клиента в таблице Customer, то вам нужно использовать Merge Join, потому что клиент может иметь 1 или более адресов, связанных с ними.

Пример для сравнения:

Вот сценарий, демонстрирующий разницу в производительности между Merge Join и Lookup. Используемые здесь данные представляют собой соединение один-к-одному, что является единственным общим сценарием для сравнения.

1. У меня есть три таблицы с именами dbo.ItemPriceInfo, dbo.ItemDiscountInfo и dbo.ItemAmount. Создание сценариев для этих таблиц предоставляется в разделе сценариев SQL.

2. Таблицы dbo.ItemPriceInfo и dbo.ItemDiscountInfo имеют по 13 349 729 строк. Обе таблицы имеют ItemNumber в качестве общего столбца. ItemPriceInfo содержит информацию о ценах, а ItemDiscountInfo - информацию о скидках. Снимок экрана # 2 показывает количество строк в каждой из этих таблиц. Снимок экрана # 3 показывает 6 верхних строк, чтобы дать представление о данных, представленных в таблицах.

3. Я создал два пакета служб SSIS для сравнения производительности преобразований Merge Join и Lookup. Оба пакета должны взять информацию из таблиц dbo.ItemPriceInfo и dbo.ItemDiscountInfo, рассчитать общую сумму и сохранить ее в таблице dbo.ItemAmount.

4. Первый пакет использовал преобразование Merge Join и внутри него он использовал INNER JOIN для объединения данных. Снимки экрана # 4 и # 5 показывают пример выполнения пакета и продолжительность выполнения. * Выполнение пакета на основе преобразования слиянием 05 минут 14 секунд 719 миллисекунд.

5. Второй использованный пакет Lookup преобразование с полным кэшем (настройка по умолчанию). скриншоты # 6 и # 7 показывают пример выполнения пакета и продолжительность выполнения. Для выполнения пакета на основе преобразования «Уточняющий запрос» потребовалось 11 минут 03 секунд 610 миллисекунд. Может появиться предупреждающее сообщение Информация: The buffer manager has allocated nnnnn bytes, even though the memory pressure has been detected and repeated attempts to swap buffers have failed. Вот ссылка , в которой рассказывается, как рассчитать размер кэша поиска. Во время выполнения этого пакета, хотя задача «Поток данных» выполнялась быстрее, очистка конвейера заняла много времени.

6. Это не означает, что преобразование «Уточняющий запрос» неверно. Просто его нужно использовать с умом. Я использую это довольно часто в своих проектах, но опять же, я не имею дело с 10+ миллионами строк для поиска каждый день. Обычно мои задания обрабатывают от 2 до 3 миллионов строк, и производительность у них действительно хорошая. До 10 миллионов строк, оба показали одинаково хорошие результаты. В большинстве случаев я замечал, что узким местом оказывается компонент назначения, а не преобразования. Вы можете преодолеть это, имея несколько направлений. Здесь - пример, демонстрирующий реализацию нескольких адресатов.

7. Снимок экрана # 8 показывает количество записей во всех трех таблицах. Снимок экрана # 9 показывает 6 лучших записей в каждой из таблиц.

Надеюсь, это поможет.

Сценарии SQL:

CREATE TABLE [dbo].[ItemAmount](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [ItemNumber] [nvarchar](30) NOT NULL,
    [Price] [numeric](18, 2) NOT NULL,
    [Discount] [numeric](18, 2) NOT NULL,
    [CalculatedAmount] [numeric](18, 2) NOT NULL,
CONSTRAINT [PK_ItemAmount] PRIMARY KEY CLUSTERED ([Id] ASC)) ON [PRIMARY]
GO

CREATE TABLE [dbo].[ItemDiscountInfo](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [ItemNumber] [nvarchar](30) NOT NULL,
    [Discount] [numeric](18, 2) NOT NULL,
CONSTRAINT [PK_ItemDiscountInfo] PRIMARY KEY CLUSTERED ([Id] ASC)) ON [PRIMARY]
GO

CREATE TABLE [dbo].[ItemPriceInfo](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [ItemNumber] [nvarchar](30) NOT NULL,
    [Price] [numeric](18, 2) NOT NULL,
CONSTRAINT [PK_ItemPriceInfo] PRIMARY KEY CLUSTERED ([Id] ASC)) ON [PRIMARY]
GO

Скриншот № 1:

Скриншот № 2:

Снимок экрана № 3:

Снимок экрана № 4:

Снимок экрана № 5:

Снимок экрана № 6:

Снимок экрана № 7:

Снимок экрана № 8:

Снимок экрана № 9:

Answer 2

Соединение слиянием предназначено для получения результатов, аналогичных тому, как JOIN работает в SQL. Компонент «Уточняющий запрос» не работает как SQL JOIN. Вот пример, где результаты будут отличаться.

Если между входом 1 (например, счета-фактуры) и входом 2 (например, позициями счета-фактуры) есть отношение один ко многим, вы хотите, чтобы результаты объединения этих двух входов включали одну или несколько строк для один счет.

С Merge Join вы получите желаемый результат. При использовании функции «Уточняющий запрос», где вход 2 является источником поиска, выходной файл будет составлять одну строку на каждый счет-фактуру, независимо от того, сколько строк существует на входе 2. Я не помню, какая строка из входа 2 получала данные, но я Я уверен, что вы получите предупреждение о дубликатах данных, по крайней мере.

Итак, каждый компонент имеет свою роль в SSIS.

Answer 3

Я предложу третий вариант для рассмотрения. Ваш OLE DBSource может содержать запрос, а не таблицу, и вы можете выполнить соединение там. Это не хорошо во всех ситуациях, но когда вы можете использовать его, вам не нужно предварительно сортировать.

Answer 4

есть 2 различия:

1. Сортировка:

   • объединение слиянием требует оба входных данных для сортировки одинаково
   • поиск не требует сортировки ввода.

2. Загрузка запроса к базе данных:

   • объединение слиянием не относится к базе данных, а только к двум входным потокам (хотя справочные данные обычно имеют вид 'select * from table order by critera объединения')
   • lookup выдаст 1 запрос для каждого (отдельного, если кэшированного) значения, к которому его просят присоединиться. Это быстро становится дороже, чем вышеупомянутый выбор.

Это приводит к: если не нужно создавать отсортированный список, и вы хотите, чтобы более чем 1% строк (одна строка выбирается в ~ 100 раз дороже той же строки при потоковой передаче) (вы не хотите сортировать 10 миллионов строк таблица в памяти ..) тогда объединение объединением - путь.

Если вы ожидаете только небольшое количество совпадений (при поиске различных значений, когда включено кэширование), то поиск лучше.

Для меня компромисс между этими двумя находится между 10k и 100k строк, которые нужно искать.

Тот, который быстрее, будет зависеть от

• общее количество строк для обработки. (если таблица является резидентной памятью, сортировка данных для слияния обходится дешево)
• ожидаемое количество повторных поисков. (высокие накладные расходы на поиск по строке)
• если вы можете выбрать отсортированные данные (обратите внимание, что сортировка текста зависит от сортировки кода, поэтому будьте осторожны, так как то, что sql считает отсортированным, также то, что ssis считает отсортированным)
• какой процент от всей таблицы вы будете искать. (объединение потребует выбора каждой строки, поиск лучше, если у вас есть только несколько строк на одной стороне)
• ширина строки (количество строк на странице может сильно влиять на стоимость выполнения одного поиска по сравнению со сканированием) (узкие строки -> больше предпочтений для слияния)
• порядок данных на диске (легко производить отсортированный вывод, предпочтительнее объединение, если вы можете организовать поиск в порядке физического диска, поиск обходится дешевле из-за меньшего количества кеш-пропусков)
• сетевая задержка между сервером ssis и местом назначения (большая задержка -> предпочтительнее слияние)
• сколько усилий по программированию вы хотите потратить (объединение написать немного сложнее)
• сопоставление входных данных - объединение служб SSIS имеет странные представления о сортировке текстовых строк, которые содержат не алфавитно-цифровые символы, но не являются nvarchar. (это относится к сортировке, и заставить sql выдать сортировку, которую ssis рад объединить, сложно)

Answer 5

Поиск аналогичен левому соединению в компоненте Merge Join.Объединение может выполнять другие типы объединений, но если это именно то, что вам нужно, разница в основном в производительности и удобстве.

Их характеристики производительности могут сильно различаться в зависимости от относительного объема данных.для поиска (входные данные для компонента поиска) и объем ссылочных данных (размер кэша поиска или размер источника данных поиска).

Например, если вам нужно только просмотреть 10 строк, но набор ссылочных данных равен 10 миллионам строк - поиск с использованиемрежим частичного или нулевого кэширования будет быстрее, поскольку он будет получать только 10 записей, а не 10 миллионов.Если вам нужно найти 10 миллионов строк, а ссылочный набор данных - 10 строк - полностью кэшированный Lookup, вероятно, быстрее (если эти 10 миллионов строк уже не отсортированы, и вы можете попробовать объединить слияние).Если оба набора данных велики (особенно если их больше, чем доступно в ОЗУ) или отсортирован больший объем, возможно, лучшим выбором будет Merge.

Answer 6

Я знаю, что это старый вопрос, но я считаю, что одна критическая точка не была охвачена данными ответами: поскольку объединение слиянием объединяет два потока данных, оно может объединять данные из любого источника. В то время как при поиске один источник данных должен храниться в OLE DB.

Answer 7

Объединение слиянием позволяет объединять несколько столбцов на основе одного или нескольких критериев, в то время как поиск более ограничен в том смысле, что он выбирает только одно или несколько значений на основе некоторой соответствующей информации столбца - запрос поиска будетзапустите для каждого значения в вашем источнике данных (хотя SSIS будет кэшировать источник данных, если это возможно).

Это действительно зависит от того, что содержат ваши два источника данных и как вы хотите, чтобы ваш окончательный источник выглядел после слияния.Не могли бы вы предоставить более подробную информацию о схемах в вашем пакете DTS?

Еще одна вещь, которую следует учитывать, это производительность.При неправильном использовании каждый из них может работать медленнее другого, но, опять же, он будет зависеть от объема данных, который у вас есть, и ваших схем источников данных.