Американский Наблюдатель

Я делал C# + SQL пакеты для UPS. Там был стандатртный EDI файл на входе, из которого мне надо было 10%

Любое изменение .NET кода требует множества усилий. SSIS - один файл и легко копируется на разные сервера, не требуя изменений.

Совмещать application и DB сервера в одном - плохая практика.

Типичная задача - собрать XML файлы с десятка FTP серверов и загрузить в SQL базу.

>Кто использует то, что ты написал?
http://yostrov.livejournal.com/30070.html

Edited Date: 2016-06-08 12:33 am (UTC)

From:

"Совмещать application и DB сервера в одном - плохая практика. "

вот кровью под этим подпишусь много этого тут до неприличья.
Расскажи про проект если будет шанс ну просто интересно.

From:

Первая задача - систематизировать overnight сбор данных со всех POS.

From:

В реале или лог? Идет апдейт или с-до а до+1-финальное состояние?

From:

Лог. Сейчас десяток разных систем, по типам POS.

В моем стартапе - в реале, через WebService

From:

Вангую: нет прямого фида на аппаратуру. Оптимизация?

From:

Kак файл попадает на FTP - Не мои проблемы.

From:

А у меня вот полный аппаратный фид. Тоесть данные ко мне на алгоритм (NN classification) потом backfeed и опять классификация и так много раз. А не написана пока обработка для неклассифицированного ("что там спрятано внутри").
Начальный фид распределен.
Такая жизнь.
Локхид совсем рядом делает похожее но с аппаратным фидом я туда хочу но мне слабо потому что локхид и дети-малосовместимы. Я даже не подавала после фиаско с одной классной конторкой в которой был очень вкусный проект.

From:

10-4.livejournal.com

У локхида достаточно вкусные зарплаты :)

From:

"В моем стартапе - в реале, через WebService "Вот реал меня волнует безмерно не могу кушать и спать. Потому что сканирование веба открывает совершенно адские перспективы.
Останавливает медленность процесса порождаемая проблемой классификации (размытые границы кастера).
Вот я знаю что в локхиде получится и очень хочется в этом поучаствовать вот хоть на луну вой.
Я чуть в Неваду не подалась посменно там похожая задачка была по GIS но реалии школьного пикапа после 3 вернули меня с небес (откуда эти gis берут) на твердую почву.

From:

> Любое изменение .NET кода требует множества усилий.

Если этим занимаешься постоянно, то все эти усилия отлично автоматизируются:
1) Покрытие авто-тестами и автоматическое выполнение всех авто-тестов после code commit.
2) Создание deployment package.
3) Сам deployment to production тоже хорошо автоматизируется.

А как сделать code review SSIS package после того, как ты добавишь пару колонок?
Сколько текста поменяется в результирующем SSIS скрипте?
Ты вообще на результирующий SSIS код смотришь, или только на картинки/таблицы?

> Типичная задача - собрать XML файлы с десятка FTP серверов и загрузить в SQL базу.

Так я тоже такую же задачу постоянно решаю.
И использовать для этого SSIS мне даже в голову не приходило.
Ведь SSIS слишком неуклюжий для этого.
Например, что делать, если одного из файлов нет?
Или он не парсится по какой-то причине?
Или XML нужно предварительно разархивировать.
Или формат нестандартный.
Или скачать нужно не с FTP, а c HTTP.

Нужен же custom code для обработки таких событий. И, как правило, полноценный C# application с этим справляется гораздо лучше, чем куцый SSIS, где всё собирается на коленке.

From:

>полноценный C# application с этим справляется гораздо лучше, чем куцый SSIS
Вот только цена у них разная.

From:

> Вот только цена у них разная.

Я предполагаю, что в относительно простых случаях первоначальная разработка SSIS package может быть и ниже, чем у полноценного C#+SQL application, но стоимость поддержки SSIS package, вероятно, гораздо выше, чем стоимость поддержки C#+SQL application.
Нужно же как-то за всеми этими разбросанными package следить. Как-то убеждаться, что изменения ничего не поломали.
Если нормального code review изменений нет, авто-тестов нет, то куча багов обнаружатся уже только в production. Что очень, очень дорого обходится.

Теперь я лучше понимаю, почему некоторые из моих партнёров по интеграции XML feeds (на противоположной стороне) так мучаются.

From:

>стоимость поддержки SSIS package, вероятно, гораздо выше, чем стоимость поддержки C#+SQL application.
Нет.

>Нужно же как-то за всеми этими разбросанными package следить.
Все package собираются в одном сервере, если надо.

>Как-то убеждаться, что изменения ничего не поломали.
Если есть сообщение об ошибке - значит сломали :)

From:

> Если есть сообщение об ошибке - значит сломали :)

А если сообщения об ошибке нет - значит ли это, что SSIS package работает правильно?

Ты, кстати, так и не ответил, можно ли просматривать изменения в SSIS package?

Код SSIS, на твой взгляд, достаточно читабельный для того, чтобы посмотреть diff?

From:

>А если сообщения об ошибке нет - значит ли это, что SSIS package работает правильно?
Если никто ни на что не жалуется - не трогай систему!

>Ты, кстати, так и не ответил, можно ли просматривать изменения в SSIS package?
Можно. TFS например.

>Код SSIS, на твой взгляд, достаточно читабельный для того, чтобы посмотреть diff?
Глазами - нет. version control software - да. А зачем? Если надо выбрать нужный пакет из двух с одинаковыми именами, то проверяется один-два объекта обычно. В зависимости от сложности пакета, конечно.

From:

> Если никто ни на что не жалуется - не трогай систему!

А если нужно добавить пару полей, но, вместе с тем, убедиться в том, что feed продолжает парситься после изменения SSIS package?

Количество таблиц до и после изменения одинаковое.

Заглядываешь в TFS посмотреть изменения - а там только визуальные картинки. Очень друг на друга похожие.
Как проверить, что при изменении SSIS package ничего по-ошибке не изменили?

Пользователи, конечно, ошибку тоже найдут. Но, возможно, только через пол-года.
И будут очень, очень расстроены потерей этих данных.

From:

> Совмещать application и DB сервера в одном - плохая практика.

Почему?
Они же используют разные ресурсы.

DB server, в основном, потребляет диск и память.
Application, в основном, потребляет процессор. Да и вообще мало что потребляет.

From:

SQL сервер не только потребляет процессор, но и полностью его блокирует под себя, так же как и память.

>Application, в основном, потребляет процессор. Да и вообще мало что потребляет.
Похоже, что вы не понимаете, о чём пишете.

From:

> SQL сервер не только потребляет процессор, но и полностью его блокирует под себя

Вот так вот весь процессор, со всеми его 8+ ядрами?
Где про это можно прочитать?

> Похоже, что вы не понимаете, о чём пишете.

www.postjobfree.com уже много лет на одной машине имеет SQL server + IIS + Windows Service, который, загружает сотни XML feeds каждый день.

Всё работает довольно быстро.

Хотя я вполне допускаю, что на Azure так бы не получилось
:-)

From:

У тебя свой личный сервер, на котором работает только одна задача.
В корпорациях обычно десятки и сотни задач крутятся на одном сервере, часто мешают друг другу.

https://channel9.msdn.com/Forums/Coffeehouse/IIS-and-SQL-on-the-same-server-or-VM-

Azure - он разный. Есть A0, есть D15. Еще можно сделать G5
Я стараюсь рекомендовать пользоваться не VMs, а services. Including SQL DB. Price from $5/month to $7000/month

From:

> У тебя свой личный сервер, на котором работает только одна задача.

У меня очень много задач.
Какие-то выполняются последовательно, какие-то параллельно в разных тредах.

Но всё это вполне умещается в IIS + single Windows Service.

> https://channel9.msdn.com/Forums/Coffeehouse/IIS-and-SQL-on-the-same-server-or-VM-

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

Возможно, ты имел ввиду вот это:
"by default it will eat up all the memory on the box given a chance"

Но ничто же не мешает ограничить память, выделяемую SQL Server-у.

> Я стараюсь рекомендовать пользоваться не VMs, а services.

Windows services или Web services?
И почему рекомендуешь?

From:

Choose a cloud SQL Server option: Azure SQL (PaaS) Database or SQL Server on Azure VMs (IaaS)
https://azure.microsoft.com/en-us/documentation/articles/data-management-azure-sql-database-and-sql-server-iaas/

Если у меня 8 ядер - я обязан купить лицензии на все. Потом ограничивать их использование будет глупо.

From:

> Choose a cloud SQL Server option: Azure SQL (PaaS) Database or SQL Server on Azure VMs (IaaS)
> https://azure.microsoft.com/en-us/documentation/articles/data-management-azure-sql-database-and-sql-server-iaas/

Это ты так объясняешь почему ты рекомендуешь "пользоваться не VMs, а services"?

> Если у меня 8 ядер - я обязан купить лицензии на все.

Лицензии на SQL Server привязываются к числу процессоров, а не к числу ядер.

> Потом ограничивать их использование будет глупо.

Типичный business app потребляет гораздо меньше ресурсов, чем SQL Server.
В том числе, в сценарии ETL.

From: