Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Перенос процесса.  [new]
dermama
Member

Откуда:
Сообщений: 226
Коллеги, добрый вечер.

Есть идея перенести все банковские процессы и реализовать их ПОЛНОСТЬЮ посредством dtsx пакетов с отказом от процедур. В данный момент базу обслуживают процедуры, немного dtsx пакетов, однако в VS пакет представляет собой этапы с однойменными процедурами, ссылающиеся на последние.
Вопрос: 1) возможно ли перенести обслуживание всех процессов посредством SSIS пакетов?
2) возможно ли почти полностью отказаться от процедурной части, которая в данный момент эксплуатируется?
3) какие положительные моменты появятся в случае успешной реорганизации?
4) какие отрицательные моменты появятся в случае реализации?

С уажением
ваш коллега.
5 июн 19, 22:26    [21902984]     Ответить | Цитировать Сообщить модератору
 Re: Перенос процесса.  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36989
Зачем? Заняться нечем особо?
5 июн 19, 23:01    [21902999]     Ответить | Цитировать Сообщить модератору
 Re: Перенос процесса.  [new]
dermama
Member

Откуда:
Сообщений: 226
Гавриленко Сергей Алексеевич
Зачем? Заняться нечем особо?


SSIS пакеты работают быстрее. Хочу ускорить процессы.
5 июн 19, 23:04    [21903004]     Ответить | Цитировать Сообщить модератору
 Re: Перенос процесса.  [new]
vikkiv
Member

Откуда: London
Сообщений: 2704
dermama,

1) возможно, SSIS всё-таки workflow среда со скриптовыми блоками, так что реализация практически любой программной логики вполне возможна
2) конечно, например элементарно посылая текст процедуры на исполнение в виде SQL скрипта вместо того чтобы её вызывать на сервере готовую
3) и 4) - зависит от специфики текущего процесса и как это реализовать на SSIS, универсального ответа нет, у SSIS есть свои преимущества у SQL/DB свои, можно просто разбить процесс используя лучшее из каждого решения для компенсации недостатков/слабостей другого.

если есть необходимость и такая задача с реальной пользой от результата - то вперёд, иначе: работает - не трожь
5 июн 19, 23:21    [21903012]     Ответить | Цитировать Сообщить модератору
 Re: Перенос процесса.  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36989
dermama
SSIS пакеты работают быстрее. Хочу ускорить процессы.
Не может условный join работать вне сервера быстрее, чем внутри. Но если у вас альтернативно одаренный код внутри TSQL-процедур, то это не повод переносить все наружу -- надо просто это разгрести, что у вас там понаписано.
5 июн 19, 23:26    [21903016]     Ответить | Цитировать Сообщить модератору
 Re: Перенос процесса.  [new]
vikkiv
Member

Откуда: London
Сообщений: 2704
Гавриленко Сергей Алексеевич,

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

о преимуществах - SSIS в некоторых сценариях легче отслеживать прогресс
(хотя и в процедурах можно результаты пошагово в служебные таблицы писать)
как недостаток - вроде ведь SSIS умирает давно .. вся нормальная автоматизация глубоко в скрипты уходит
5 июн 19, 23:35    [21903020]     Ответить | Цитировать Сообщить модератору
 Re: Перенос процесса.  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31371
Перенести логику из хранимых процедур в сервер приложений - ещё понятная идея. Хотя ИМХО плохая.

Но идея использовать SSIS как сервер приложений - это совсем никуда не годиться.
Вы не сможете это нормально разрабатывать и поддерживать.
Да и работать будет очень медленно.
6 июн 19, 08:02    [21903094]     Ответить | Цитировать Сообщить модератору
 Re: Перенос процесса.  [new]
.Евгений
Member

Откуда:
Сообщений: 521
Гавриленко Сергей Алексеевич
Не может условный join работать вне сервера быстрее, чем внутри.

Может и легко. У SSIS намного меньшие издержки, ему не нужно поддерживать транзакционность, лог, статистику выполнения и т.п.

Разрабатываю всю загрузку ХД посредством SSIS, начиная от получения данных из шины (напрямую), файлов, таблиц БД. Пакеты крутятся на выделенном сервере ETL и минимально нагружают основной сервер ХД. Работает быстро, потребляет мало.
6 июн 19, 10:04    [21903202]     Ответить | Цитировать Сообщить модератору
 Re: Перенос процесса.  [new]
invm
Member

Откуда: Москва
Сообщений: 9351
.Евгений
У SSIS намного меньшие издержки, ему не нужно поддерживать транзакционность, лог, статистику выполнения и т.п.
SSIS умеет забирать данные из MSSQL мимо транзакционности и статистики выполнения?
Чем нагружается лог при чтении?
Как выполнить соединение на клиенте не выкачав все данные в нем участвующие?
6 июн 19, 10:19    [21903217]     Ответить | Цитировать Сообщить модератору
 Re: Перенос процесса.  [new]
.Евгений
Member

Откуда:
Сообщений: 521
invm
SSIS умеет забирать данные из MSSQL мимо транзакционности и статистики выполнения?Чем нагружается лог при чтении?

Я отвечал на вопрос о join-е. Давайте не будем произвольно расширять вопрос и притворяться глупее, чем мы есть.
invm
Как выполнить соединение на клиенте не выкачав все данные в нем участвующие?

ETL-средство не может оптимизировать непосредственно выкачку данных из таблиц и очень ограниченно - вставку, за счет разбиения на порции. Основная выгода получается за счет операций над выкачанными наборами данных (начиная с декомпозиции запросов к источникам).
6 июн 19, 10:37    [21903233]     Ответить | Цитировать Сообщить модератору
 Re: Перенос процесса.  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
радует, мышкопрограммисты атакают

автор
. Основная выгода получается за счет операций над выкачанными наборами данных (начиная с декомпозиции запросов к источникам).

мы поставили второй сервер что бы сказать что теберь всё быстрее на первом
6 июн 19, 10:43    [21903238]     Ответить | Цитировать Сообщить модератору
 Re: Перенос процесса.  [new]
invm
Member

Откуда: Москва
Сообщений: 9351
.Евгений
Я отвечал на вопрос о join-е. Давайте не будем произвольно расширять вопрос и притворяться глупее, чем мы есть.
А мои вопросы к чему относятся?
Или join в SSIS - это некая магия?

Есть тут на форуме один персонаж, который некоторое время назад утверждал, что "мержить" данные из БД в SSIS гораздо выгоднее, чем на сервере. Доказать не смог.
У вас пока что тоже с доказательствами беда...
6 июн 19, 10:54    [21903254]     Ответить | Цитировать Сообщить модератору
 Re: Перенос процесса.  [new]
.Евгений
Member

Откуда:
Сообщений: 521
TaPaK
радует, мышкопрограммисты атакают

Вы напомнили мне одного моего дальнего родственника, программиста на плюсах. Как-то раз он мимоходом сказал, что SQL - это не программирование, а так. Я в ответ хмыкнул, пожал плечами и подумал: молодой еще, авось потом поймет.
Лично я комбинирую внутри SSIS квадратики, SQL и C#, выбирая то, что проще и эффективнее решит конкретную потребность. У меня три инструмента, у других один.
TaPaK
мы поставили второй сервер что бы сказать что теберь всё быстрее на первом

Именно так. И это очень хорошая практика, когда нагрузку можно разнести по разным машинам в зависимости от ее типа, изолировать постоянно работающий ETL от аналитических запросов.
invm
А мои вопросы к чему относятся?
Или join в SSIS - это некая магия?

Не магия, по сути это обычный merge join.
Как только вы захотите изменить данные посредством join внутри СУБД, вы сталкиваетесь с теми самыми издержками, о которых я говорил выше. Без изменения данных это не ETL и потому оффтопик.
invm
Есть тут на форуме один персонаж, который некоторое время назад утверждал, что "мержить" данные из БД в SSIS гораздо выгоднее, чем на сервере. Доказать не смог.
У вас пока что тоже с доказательствами беда...

Если рассматривать понятие "мержить" максимально широко, то я соглашусь с тезисом этого персонажа. Доказываю это своим работающим решением моему руководству и работодателю. Доказывать лично вам... ну, если вежливо попросите.
6 июн 19, 11:30    [21903288]     Ответить | Цитировать Сообщить модератору
 Re: Перенос процесса.  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
автор
Как только вы захотите изменить данные посредством join внутри СУБД

дивный новый мир
6 июн 19, 11:32    [21903294]     Ответить | Цитировать Сообщить модератору
 Re: Перенос процесса.  [new]
invm
Member

Откуда: Москва
Сообщений: 9351
.Евгений
Не магия, по сути это обычный merge join.
А входные данные для merge кто будет сортировать?
.Евгений
Как только вы захотите изменить данные посредством join внутри СУБД, вы сталкиваетесь с теми самыми издержками, о которых я говорил выше.
Как интересно.
Оказывается SSIS еще и писать умеет в БД минуя транзакционность и статистику выполнения. Не говоря уже о том, что посредством join данные в БД изменить нельзя.
.Евгений
Доказываю это своим работающим решением моему руководству и работодателю.
Работоспособность решения не есть доказательство его превосходства над другими работоспособными решениями.
6 июн 19, 12:04    [21903338]     Ответить | Цитировать Сообщить модератору
 Re: Перенос процесса.  [new]
.Евгений
Member

Откуда:
Сообщений: 521
invm
А входные данные для merge кто будет сортировать?

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

Вы цепляетесь к словами, что, на мой взгляд, не имеет разумной цели. Если вам так не нравится слово "посредством", я напишу "с применением join". Вопрос исчерпан?

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

Согласен с вами. Более того, я считаю это очевидным не только для нас, но и для моего руководства.
6 июн 19, 12:28    [21903361]     Ответить | Цитировать Сообщить модератору
 Re: Перенос процесса.  [new]
Кесарь
Member

Откуда:
Сообщений: 453
Как только люди не извращаются!


А каков размер базы в общем и размер средней таблицы, каков поток чтений и записей?
6 июн 19, 12:39    [21903375]     Ответить | Цитировать Сообщить модератору
 Re: Перенос процесса.  [new]
.Евгений
Member

Откуда:
Сообщений: 521
Кесарь,

до 500 xml сообщений (по 1-100 кб) в секунду, таблицы до нескольких сотен млн записей, задержка обновления данных до пары минут (от появления сообщения в шине), минимальное влияние на сервер ХД (короткие insert и update). Посредственное виртуальное железо. Реализованы разрешение идентификаторов без ограниченного окна загрузки; СККД и автоматическая загрузка после исправления ошибки (например, элемент справочника пришел позже ссылающегося на него факта).
6 июн 19, 12:54    [21903403]     Ответить | Цитировать Сообщить модератору
 Re: Перенос процесса.  [new]
Кесарь
Member

Откуда:
Сообщений: 453
Так у вас затык получается в моменте вставки данных из внешних систем, я правильно понял?

Не знаю как вы собрались работать на SSIS-е, ИМХО он слабо предрасположен для этого. Вещь очень плохо поддерживаемая. Лучше туда никакую логику не засовывать, умучаетесь потом. Прочем дело ваше.

Как мне видится расшивка этого узкого места:

вся входящая инфа валится на «сервер» (это может быть вовсе не один сервер, впрочем в этих технологиях я не очень), на котором работают микросервисы (что позволяет широкое масштабирование в зависимости от нагрузки), которые парсят XML-сообщения и складывают в некую достаточно лёгкую базу. Задачей базы является присвоение сквозного ID каждой сущности и отправка её в обмен. Из обмена она уже забирается основной базой, в которой лежит вся инфа и реализована бизнес-логика на процедурах. Лёгкая база регулярно чистится, ессно.
6 июн 19, 13:13    [21903424]     Ответить | Цитировать Сообщить модератору
 Re: Перенос процесса.  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
.Евгений
Кесарь,

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

server broker курильщика
6 июн 19, 13:21    [21903432]     Ответить | Цитировать Сообщить модератору
 Re: Перенос процесса.  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7780
dermama,

SSIS работаю эффективно при обработке и загрузке данных из внешних источников. Для внутрисерверных запросов оптимальны типовые SQL запросы. Основное преимущество SSIS в том, что с их помощью можно достаточно быстро обрабатывать потоки внешних данных без создания локальных "перевалочных" буферов.
6 июн 19, 13:35    [21903459]     Ответить | Цитировать Сообщить модератору
 Re: Перенос процесса.  [new]
.Евгений
Member

Откуда:
Сообщений: 521
Кесарь,

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

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

Бизнес-логику, удовлетворяющую заданным требованиям, посредством одного SQL реализовать невозможно (мое личное мнение). Если не углубляться, то не получится совместить минимальные задержку и влияние.
TaPaK
server broker курильщика

Уже был RabbitMQ.
Кроме того, я не видел решение, позволяющее парсить такой поток сообщений на таком железе. Поэтому сделал так, как сделал.
6 июн 19, 13:36    [21903465]     Ответить | Цитировать Сообщить модератору
 Re: Перенос процесса.  [new]
invm
Member

Откуда: Москва
Сообщений: 9351
.Евгений
Либо сервер БД, либо SSIS.
Т.е. об этих дополнительных накладных расходах вы решили скромно умолчать?
.Евгений
Вы цепляетесь к словами, что, на мой взгляд, не имеет разумной цели.
Да неужели? Вы просто не в состоянии внятно объяснить свои пассажи и путаетесь в показаниях.
.Евгений
В одном случае транзакция блокирует таблицы-источники, а также ресурсы для преобразований данных.
Да? И как же она их блокирует так, что они остаются монопольно заблокированными на время транзакции? И, главное, зачем?
И что такое ресурсы для преобразования данных? И чтоб эти ресурсы не блокировались нужно добавить отдельный сервер для ETL со своими ресурсами? А лучше несколько, так сказать для надежности?
6 июн 19, 13:38    [21903467]     Ответить | Цитировать Сообщить модератору
 Re: Перенос процесса.  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7780
Выделение машины под ETL требуется в случае обработки несортированных данных значительного объема. То есть при объемах, начиная с нескольких десятков гигабайт и загруженностью 24/7. В других случаях выглядит избыточным...
6 июн 19, 13:45    [21903480]     Ответить | Цитировать Сообщить модератору
 Re: Перенос процесса.  [new]
Кесарь
Member

Откуда:
Сообщений: 453
.Евгений
Кесарь,

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


Тогда я не понял, в чём проблема.


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


И ещё раз не понял.

Бизнес-логика легко реализуется на sql любая, которая может быть представлена в виде транзакций (у вас ведь не управление атомной станцией?). Банковские операции заведомо реализуемы в sql. По определению.

Задержки относятся не к бизнес-логике, а к архитектуре, качеству кода, качеству работы команды админов и наконец просто напросто к мощности железа.

Что есть "влияние" я тоже не понял.


В общем то ли вы не можете сформулировать ясными словами ваши проблемы, то ли их вовсе нет, то ли вы их сами не до конца понимаете.
6 июн 19, 13:53    [21903489]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить