Преимущества использования пакетов SSIS по хранимым процедурам? [закрытый]
Конечно, причина, по которой вы находите дополнительный процесс, состоит в том, что:
Один процесс выполняет под-оболочку (выполнения команды `..`), включенную в вашу строку: numscr=`ps aux | grep ScreamDaemon.sh | wc -l`;
, это самый простой ответ.
Однако я хотел бы сделать несколько дополнительных предложений о вашем коде:
Во-первых, укажите ваши расширения, это должно быть: echo "$str". Нельзя сделать несколько строк в одном длинном.
Во-вторых, вы можете использовать: grep [S]creamDaemon.sh, чтобы избежать совпадения самой команды grep.
В-третьих, захватите команду просто один раз в переменной, а затем подсчитать строки из переменной. В этом случае это не проблема, но для динамических процессов один захват и следующий захват для подсчета могут давать разные результаты.
В-четвертых, привычка использовать $(...) подстановки команд вместо более склонной к ошибкам (особенно при Nesting) `...`.
### Using a file as the simplest way to capture the output of a command
### that is running in this shell (not a subshell).
ps aux | grep "[S]creamDaemon.sh" > "/tmp/tmpfile$$.txt"
str="$(< "/tmp/tmpfile$$.txt")" ### get the value of var "str"
rm "/tmp/tmpfile$$.txt" ### erase the file used ($$ is pid).
numscr="$(echo "$str" | wc -l)" ### count the number of lines.
echo "$numscr" ### present results.
echo "$str"
str="$( ps aux | grep "[S]creamDaemon.sh" )" ### capture var "str".
numscr="$(echo "$str" | wc -l)" ### count the number of lines.
echo "$numscr" ### present results.
echo "$str"
### The only bashim is the `$(<...)`, change to `$(cat ...)` if needed.
@CharlesDuffy достаточно хорошо рассмотрел точку flock, , прочитав ее .
10 ответов
Если ваш ETL в основном состоит из E и L, с очень маленьким T, и если вы можете написать свои SP, чтобы они не полагались на курсоры, тогда, вероятно, подойдет маршрут только SP .
Для более сложных процессов, особенно тех, которые включают тяжелые преобразования, медленно меняющиеся измерения, поиск данных и т. Д., SSIS имеет три преимущества.
Во-первых, он очень эффективно управляет памятью, что может привести к значительному повышению производительности по сравнению с только с T-SQL.
Во-вторых, графический интерфейс позволяет создавать большие, сложные и надежные преобразования намного проще, чем ручной T-SQL.
И, в-третьих, SSIS позволяет вам более легко взаимодействовать с дополнительными внешними источниками , что может быть очень удобно для таких вещей, как очистка данных.
Я жил в стране хранимой процедуры ETL для многотерабайтного хранилища данных SQL Server. Это решение было принято еще в 2001 году, когда .NET был 1.0, поэтому VB6 был альтернативой языка программирования, а SSIS еще не существовал - это был DTS. Я могу сказать вам, что были преимущества и недостатки, как и все.
Некоторые соображения:
- Если все в вашей команде понимают SQL, легко разобраться в хранимых процессах. SQL - широко известный навык, который может быть полезен, если у вас много писателей / читателей ETL. Вы должны быть не просто обычным пользователем SSIS, чтобы понять, что он делает. Графический поток высокого уровня удобен для документирования, но если кому-то нужно разобраться с духом, ему лучше знать SSIS.
- SQL - это боль в модульности. Если вы используете UDF, вы получите огромный удар по производительности. Вы будете писать похожий код в нескольких местах, и вы будете ненавидеть себя за это, но часто в сценариях ETL производительность является главной. Служба SSIS поможет вам модульно структурировать ваши задачи.
- Не ожидайте, что сможете легко использовать контроль источников с SSIS. SQL - нет проблем. SSIS использует ужасные XML-файлы, которые можно зарегистрировать, но удачи в предыдущих версиях, чтобы увидеть, что изменилось и когда.
- Вы должны думать о своих SP по модульному принципу, хотя трудно сделать их такими модульными, как бы вам хотелось. Используйте временные таблицы для разделения вашей обработки. Поместите индексы в эти временные таблицы, прежде чем использовать их. Не пытайтесь делать слишком много сразу. Комментируйте все.
- Если вы используете курсоры, вы делаете это неправильно. Не бойтесь связать какое-то внешнее консольное приложение, написанное вами на выбранном вами языке, для выполнения некоторых задач, для которых SQL просто не предназначен.
Кстати, после того, как я покинул эту компанию, они наконец обновили базу данных с SQL 2000 до 2008 и медленно перешли с хранимых процедур на SSIS. В моей новой компании у нас есть SSIS, но после его использования мы все согласились с тем, что наш заказный .NET ETL лучше подходит для наших целей. Каждый идет своим путем. Решение должно сбалансировать обслуживание и производительность, а также набор навыков вашей команды и набор навыков пула заданий в вашем регионе.
Я бы сказал, что это зависит от того, что вы делаете. Однако, по моему опыту, возможности для улучшения с помощью пакетов служб SSIS огромны. Мы увидели 10-кратное улучшение в нашей среде хранилища данных, когда взяли некоторые из самых сложных хранимых процедур и поместили их в пакеты служб SSIS. Использование памяти SSIS (в любом случае, в этой ситуации) имело все значение.
Я хочу повторить, что важно знать, что вы делаете. Например, оператор SQL обычно превосходит поток данных SSIS, когда преобразование данных является таблицей на одном и том же сервере.
Лучше всего выбрать SP или два, создать их в SSIS и протестировать их обоих.
Похоже, что ответ на все вопросы SQL начинается с, Это зависит ...
Я видел огромный прирост производительности от использования SSIS, особенно хорошо, если у вас есть хранимые процедуры, использующие связанные серверы, так как это требует большей вычислительной мощности, а связанные серверы имеют тенденцию перетаскивать всю таблицу в память перед ограничением строк нужен для соединения. У нас была хранимая процедура, выполнение которой заняло более 7 часов, я разбил ее на данные с каждого сервера, а затем настроил локальный источник данных для каждого в SSIS, позволяя выполнять обработку локально для каждого источника данных, как это делается через связанный сервер, работа теперь занимает 6 минут, я бы сказал, что это огромный выигрыш.
Caralyn
В SSIS отсутствуют некоторые базовые функции, в нем нет пакета типа Informatica, позволяющего запускать разработку с оператором SQL для необработанных текстовых файлов, а серверу SQL крайне не хватает регистрации ошибок DML, как Oracle. Я действительно думал, что когда Microsoft объявила о добавлении заявления Merge, что, конечно, они будут реализовывать корзину ошибок, которая является одной из ее самых важных функций, думаю, еще раз. Обработка ошибок на уровне строк важна, и если вы используете оператор SQL для добавления пакетов данных, если одна запись не удалась, весь пакет откатывается.
-
Производительность будет быстрее, чем обычно SP. Не нужно создавать сложную временную таблицу, курсор, индексирование для извлечения данных.
-
Очистка данных является преимуществом служб SSIS.
-
Инкрементная обработка возможна только в ssis.
-
Мы можем создать файл конфигурации пакета и развернуть его на любом сервере. Пользователь может предоставить информацию о сервере и войти в систему.
-
Графический интерфейс пользователя.
-
Ведение журнала, обработка ошибок лучше всего в ssis.
Для небольших проектов, если у вас есть хорошие навыки работы с SQL и понимание бизнес-требований, продолжайте!
В противном случае, если вы столкнетесь с комплексными извлечения данных, тяжелые задачи преобразования Достаточно SSIS или другого инструмента ETL.
поднимает
Для передачи данных между серверами SQL используйте SSIS выше SP. Вы можете легко столкнуться с улучшением в 10 раз, как упомянуто выше. Мы перешли от 6-7 часов к более управляемым временным рамкам, включив SP в пакет SSIS
С другой стороны: SSIS - это набор XML-файлов, которыми можно манипулировать / использовать по-разному (например, для документации)
Я не вижу явных технических ограничений. Хранимая процедура может быть труднее следовать, чем пакет SSIS для сложных операций ETL, но это не будет верно для каждого сценария. Я также обнаружил, что пакеты (SSIS и DTS) легче распознать как «задания» - хранимые процедуры, которые выполняются запланированными заданиями, часто игнорируются разработчиками, поскольку они не могут видеть запланированные задания.
Тем не менее, Я видел, как ETL выполняются как хранимыми процедурами, так и пакетами DTS / SSIS, и пока хранимая процедура не представляет собой большого количества запутанного кода, это кажется подходящим. Я не
Я попробовал некоторые функции SSIS, и мне не все они понравились. Я отказался от работы с потоком данных, и я не был очень доволен производительностью, которую я увидел. В конечном итоге я разработал пакеты SSIS, в которых был поток управления задачей sql, каждый из которых выполнял хранимую процедуру.
Это обеспечило то, что SQL-сервер выполнял большую часть E, T и L. Я думаю, когда вы используете компонент потока данных, данные фактически перемещаются с сервера sql на машину, на которой запущен пакет, что делает его не таким эффективным.
Сказав это, я думаю, я бы попытался оптимизировать штуку потока данных (это было некоторое время с тех пор, как я работал на нем), если мне пришлось взаимодействовать со сторонними приложениями / базами данных / системами DW.