Гавриленко Сергей АлексеевичНе может условный join работать вне сервера быстрее, чем внутри.
Может и легко. У SSIS намного меньшие издержки, ему не нужно поддерживать транзакционность, лог, статистику выполнения и т.п.

Разрабатываю всю загрузку ХД посредством SSIS, начиная от получения данных из шины (напрямую), файлов, таблиц БД. Пакеты крутятся на выделенном сервере ETL и минимально нагружают основной сервер ХД. Работает быстро, потребляет мало.

invmSSIS умеет забирать данные из MSSQL мимо транзакционности и статистики выполнения?Чем нагружается лог при чтении?
Я отвечал на вопрос о join-е. Давайте не будем произвольно расширять вопрос и притворяться глупее, чем мы есть.
invmКак выполнить соединение на клиенте не выкачав все данные в нем участвующие?
ETL-средство не может оптимизировать непосредственно выкачку данных из таблиц и очень ограниченно - вставку, за счет разбиения на порции. Основная выгода получается за счет операций над выкачанными наборами данных (начиная с декомпозиции запросов к источникам).

TaPaKрадует, мышкопрограммисты атакают
Вы напомнили мне одного моего дальнего родственника, программиста на плюсах. Как-то раз он мимоходом сказал, что SQL - это не программирование, а так. Я в ответ хмыкнул, пожал плечами и подумал: молодой еще, авось потом поймет.
Лично я комбинирую внутри SSIS квадратики, SQL и C#, выбирая то, что проще и эффективнее решит конкретную потребность. У меня три инструмента, у других один.
TaPaKмы поставили второй сервер что бы сказать что теберь всё быстрее на первом
Именно так. И это очень хорошая практика, когда нагрузку можно разнести по разным машинам в зависимости от ее типа, изолировать постоянно работающий ETL от аналитических запросов.
invmА мои вопросы к чему относятся?
Или join в SSIS - это некая магия?
Не магия, по сути это обычный merge join.
Как только вы захотите изменить данные посредством join внутри СУБД, вы сталкиваетесь с теми самыми издержками, о которых я говорил выше. Без изменения данных это не ETL и потому оффтопик.
invmЕсть тут на форуме один персонаж, который некоторое время назад утверждал, что "мержить" данные из БД в SSIS гораздо выгоднее, чем на сервере. Доказать не смог.
У вас пока что тоже с доказательствами беда...
Если рассматривать понятие "мержить" максимально широко, то я соглашусь с тезисом этого персонажа. Доказываю это своим работающим решением моему руководству и работодателю. Доказывать лично вам... ну, если вежливо попросите.

invmА входные данные для merge кто будет сортировать?
Либо сервер БД, либо SSIS.
invmКак интересно.
Оказывается SSIS еще и писать умеет в БД минуя транзакционность и статистику выполнения. Не говоря уже о том, что посредством join данные в БД изменить нельзя.
Вы цепляетесь к словами, что, на мой взгляд, не имеет разумной цели. Если вам так не нравится слово "посредством", я напишу "с применением join". Вопрос исчерпан?

В одном случае транзакция блокирует таблицы-источники, а также ресурсы для преобразований данных.
В другом - отдельные и независимые (опционально) транзакции на чтение и изменение (обычно bulk insert).
invmРаботоспособность решения не есть доказательство его превосходства над другими работоспособными решениями.
Согласен с вами. Более того, я считаю это очевидным не только для нас, но и для моего руководства.

Кесарь,

до 500 xml сообщений (по 1-100 кб) в секунду, таблицы до нескольких сотен млн записей, задержка обновления данных до пары минут (от появления сообщения в шине), минимальное влияние на сервер ХД (короткие insert и update). Посредственное виртуальное железо. Реализованы разрешение идентификаторов без ограниченного окна загрузки; СККД и автоматическая загрузка после исправления ошибки (например, элемент справочника пришел позже ссылающегося на него факта).

Кесарь,

в общем-то у меня нет затыка. На вход загрузки подается в разы меньше данных, чем она способна обработать (средняя нагрузка около 100 сообщений/сек).

Аналог микросервисов реализован пакетами SSIS. Одна посредственная виртуалка, без контейнеров, кластеров и прочей атрибутики для лентяев.

Бизнес-логику, удовлетворяющую заданным требованиям, посредством одного SQL реализовать невозможно (мое личное мнение). Если не углубляться, то не получится совместить минимальные задержку и влияние.
TaPaKserver broker курильщика
Уже был RabbitMQ.
Кроме того, я не видел решение, позволяющее парсить такой поток сообщений на таком железе. Поэтому сделал так, как сделал.

invmТ.е. об этих дополнительных накладных расходах вы решили скромно умолчать?
Что значит - дополнительных? Join СУБД никаких расходов не несет (не сортирует для merge, не создает хеш для hash)?
invmДа? И как же она их блокирует так, что они остаются монопольно заблокированными на время транзакции? И, главное, зачем?
Вы очевидно приписали мне слово "монопольно". Вам так важен данный спор?

Успокойтесь и представьте себе две ситуации. В первом случае соединяется десяток таблиц, чтобы вставить результат в одиннадцатую. Во втором случае - все операции чтения и записи независимы. Для простоты все чтения в обоих ситуациях фуллскан. Вопрос: есть ли разница в потреблении ресурсов СУБД?
invmИ что такое ресурсы для преобразования данных?
Это выделение памяти, ядер, запись в лог, обновление статистики выполнения. Я говорю об этом максимально обще, как о том, что не расходуется SSISом или расходуется, но принципиально иначе - за счет чего можно выиграть.
invmИ чтоб эти ресурсы не блокировались нужно добавить отдельный сервер для ETL со своими ресурсами?
Вы совершенно правы.

КесарьТогда я не понял, в чём проблема.
Я не dermama, у меня нет проблемы с решением. У меня есть непонимание с человеком, притворяющимся неразумным. Но даже это не является проблемой.
КесарьБизнес-логика легко реализуется на sql любая, которая может быть представлена в виде транзакций (у вас ведь не управление атомной станцией?). Банковские операции заведомо реализуемы в sql. По определению.

Задержки относятся не к бизнес-логике, а к архитектуре, качеству кода, качеству работы команды админов и наконец просто напросто к мощности железа.
Ну хорошо, приведу конкретный пример. В таблице области Stage лежит, скажем, десять тысяч записей. Нужно "смержить" ее с соответствующей таблицей в детальной области, содержащей полмиллиарда записей, в течение 1 минуты. Спустя еще одну минуту - повторить. При этом минимально влияя (конкурируя за ресурсы) с аналитическими запросами к детальным данным. Жду предложений, как это сделать на SQL, причем на скромном виртуальном сервере.
invmТо и значит. У сервера три стратегии соединения, у SSIS - одна
И это значит, что у вас три инструмента, у меня - четыре. Понимаете разницу? Или снова прикинетесь?
Также в SSIS есть кешируемый лукап - это пятый инструмент, когда не ожидается размножение строк.
Наконец, в SSIS есть Script Task с возможностями C# - это шестой инструмент.
Конечно, в MS SQL есть CLR - но кому придет в голову использовать его для соединений?
invmКонечно приписал. Ибо без "монопольно" ваше объяснение про заблокированные "таблицы-источники" не имеет смысла.
Конечно, приписывать собеседнику свои слова в цивилизованном разговоре не стоит. Вместо этого лучше использовать вопрос: "Правильно ли я понял, что...?" и объяснить свои сомнения. Например, правильно ли я понял, что блокировки S вы блокировками не считаете?

Когда вы просто читаете таблицу-источник, то блокируете S текущую читаемую страницу, освобождая сразу по окончании чтения.
Когда вы используете таблицу-источник внутри оператора модификации данных, то блокируете с учетом эскалации S всю таблицу (прочитанные данные) и освобождаете по окончании транзакции.
С этим вы согласны или нет?
invmНу так объясните нам, неразумным
Извините, но я специально просил вас "не притворяться глупее, чем мы есть". Почему вы считаете нормальным игнорировать мою просьбу и одновременно ожидать ответа на свою? Если вы неразумный, то какой смысл тратить на вас время?
invmВы, видимо, работаете у какого-то вендора ПО.
Ибо только там считают, что клиенту дешевле купить пару-тройку новых серверов со всеми необходимыми лицензиями на софт, чем нарастить ресурсы на одном сервере.
А вам сама архитектура с выделенным сервером не кажется избыточной в сравнении с файл-серверной? Access намного дешевле MS SQL, а SQLite и вовсе бесплатен.
В моем случае две скромных виртуалки, специализированные по нагрузке, обходятся дешевле и работают эффективнее, чем один универсальный сервер. Да и надежнее.

invmНе надо уводить дискуссию в сторону. Речь идет о ваших утверждениях о преимуществе join на стороне SSIS. Итого 1.5 стратегии соединения на сторогне SSIS и 3 на стороне сервера.
Второй раз. Я сказал, что join снаружи может быть быстрее, чем join внутри. Не обязан быть быстрее всегда, а может . Используя ETL, я могу осознанно передавать ему эти случаи.
invmНе учите меня жить - это не в вашей компетенции.
Приятно повеяло годами моей молодости, а именно лозунгом "Не учите меня жить, лучше помогите материально".
Вот мне не зазорно учиться даже у неразумных людей: я приму ваши слова о блокировках к сведению и разберусь, почему у меня сложилось мнение, о котором я написал выше. Не прямо сейчас, но позже.
Если же вам кажется, будто я пытаюсь вас чему-то учить, то вы ошибаетесь. Я просто поступаю в своем стиле и объясняю, почему. Заставлять вас следовать моему примеру не стану, ибо по большому счету пофиг. Да и, как говорится, можно подвести лошадь к воде, но нельзя заставить ее пить.

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

invm не нравится сервер ETL, alexeyvg не нравится шина... Надеюсь, я не столь агрессивен и категоричен в отношении хадупа.
КесарьЕсли вы хотите, чтобы вас тут похвалили и оценили, то вы - безусловно молодец.
Когда я действительно захочу, чтобы меня оценили именно на форуме, я напишу доклад или презентацию. Пока мне достаточно оценки со стороны руководства. Хотя можно обкатать тезисы, типа "ETL имеет право на жизнь"...

invmНу вот и продемонстрируйте каким образом и засчет чего это "может" происходит. Пока что от вас только бла-бла-бла.
Т.е. вы требуете демо-пример, и ради вашего убеждения я должен развернуть тестовую среду, подготовить опытные примеры и собрать по ним статистику выполнения.
Ок, могу. Но не бесплатно. Вы готовы оплатить мой труд?
invm.ЕвгенийВпрочем, не беря в расчет конкретно блокировки и возвращаясь к преимуществам ETL, любой запрос с модификацией все равно пишет в лог, выделяет память и потоки под обработку данных - то, что SSIS не делает или делает, но совсем иначе.Еще раз - не уходите в сторону. Обсуждается join на стороне SSIS, а не преимущества ETL.
Вы не понимаете, что именно об этом я и говорил - о том, что SSIS при выполнении join не делает или делает, но совсем иначе, в сравнении с MS SQL.
invmВыделение под какую-то задачу отдельного сервера требует обоснования. Утверждение типа "я знаю как это сделать на SSIS на выделенном сервере, но не знаю как тоже самое равноэффективно реализовать на сервере БД" таковым не является.
Во-первых, реализовывать задачи на сервере БД не является самоцелью. Невыделение отдельных серверов - тоже не самоцель.
Во-вторых, отсутствие способа это частный случай незнания способа. Когда выбирается способ решения более-менее сложной задачи, то человек с опытом и без избытка тщеславия не заявит безусловную невозможность решения задачи некими средствами (в данном случае сервером БД). Он скажет: "Если такой способ и существует, то я его не знаю". И предложит свой вариант решения.
В-третьих, а знаком ли вам вкус устриц, чтобы обсуждать его в столь самоуверенной форме с теми, кто их уже ел? Приходилось ли вам работать со средствами ETL в целом и SSIS в частности и насколько глубоко?

alexeyvgЕсли нужно получить связанные с другим множеством данные, то первый вариант исключаем - join сделать надо.

По пункту "иначе", хотелось бы подробностей - какие секретные технологии скоростного join-а используются в SSIS, и почему разработчики не поделились ими с разработчиками Database Engine?
Прошу вас, читайте мои предыдущие сообщения. Повторяю свою фразу:
"У SSIS намного меньшие издержки, ему не нужно поддерживать транзакционность, лог, статистику выполнения и т.п."
alexeyvgА вы уверены, что знакомы, поэтому считаете правильным использовать в беседе настолько самоуверенные формы?
Я стараюсь избегать самоуверенности, если у меня не получилось - укажите, где это произошло.
Я не требую делать те или иные задачи на SSIS или строго доказать мне нежелательность его применения.
Но когда заявляют некую невозможность, а у меня есть противоположный опыт, то я могу им поделиться.
Если кого-то мой опыт возмущает - это его проблемы.