Стоит ли использовать SSIS или многопоточное приложение C # для загрузки плоских файлов в базу данных?

Question

В службах SQL Server Integration Services (SSIS) есть возможность настроить соединение с плоским файлом, который может содержать миллионы записей и передавать эти данные в базу данных SQL. Кроме того, этот процесс может быть вызван из приложения C # путем ссылки и использования пространства имен Microsoft.SqlServer.Dts.Runtime.

Будет ли плоский файл с миллионами записей лучше всего работать с SSIS, или коллективное «вы» предпочтет ac # app с несколькими рабочими потоками (один для чтения и добавления строки в переменную, другой для записи из этой переменной DB), а "материнский" класс, который управляет этими потоками? (в коробке разработчика есть два процессора)

Я видел эти данные ( sql team blog ) о том, что для плоского файла с миллионом строк SSIS является самым быстрым:

Process                Duration (ms)
--------------------   -------------
SSIS - FastParse ON         7322 ms 
SSIS - FastParse OFF        8387 ms 
Bulk Insert                10534 ms 
OpenRowset                 10687 ms 
BCP                        14922 ms

Что ты думаешь?

Answer 1

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

У меня около 57 рабочих мест (комбинация DTS и SSIS), которыми я управляю ежедневно. Четыре из них обычно занимаются экспортом от 5 до 100 миллионов записей. База данных, которой я управляю, насчитывает около 2 миллиардов строк. Я использовал задачу сценария, чтобы добавить дату вплоть до миллисекунды, чтобы я мог запускать задания несколько раз в день. Занимался этим около 22 месяцев. Это было здорово!

Задания SSIS также могут быть запланированы. Таким образом, вы можете установить его и забыть. Я наблюдаю за всем каждый день, но часть обработки файлов никогда не ломалась.

Единственный раз, когда мне пришлось прибегнуть к пользовательской программе на C #, это когда мне нужно было разбить очень большие файлы на более мелкие куски. Служба SSIS слишком медленная для такого рода вещей. Текстовый файл на один гигабайт занял около часа, чтобы выполнить задачу сценария. Пользовательская программа C # справилась с этим за 12 минут.

В конце, просто используйте то, что вам удобно.

Answer 2

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

Answer 3

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

Я бы рекомендовал SSIS 9 раз из десяти.