Должен ли я использовать SSIS или многопоточное приложение C# для загрузки плоских файлов в базу данных?
В службах интеграции SQL Server (SSIS) есть возможность настроить подключение к плоскому файлу, который может содержать миллионы записей, и передать эти данные в базу данных SQL. Кроме того, этот процесс можно вызвать из приложения C#, обратившись к пространству имен Microsoft.SqlServer.Dts.Runtime и используя его.
Будет ли плоский файл с миллионами записей лучше всего запускаться с SSIS, или коллективное «вы» предпочтет приложение C# с несколькими рабочими потоками (один для чтения и добавления строки в переменную, другой для записи из этой переменной в БД) , и «материнский» класс, который управляет этими потоками? (в коробке разработчика есть два процессора)
Я видел эти данные (блог команды sql), в которых говорится, что для плоского файла с миллионом строк SSIS является самым быстрым:
Process Duration (ms)
-------------------- -------------
SSIS - FastParse ON 7322 ms
SSIS - FastParse OFF 8387 ms
Bulk Insert 10534 ms
OpenRowset 10687 ms
BCP 14922 ms
о чем ты думаешь?
Ответы 3
SSIS невероятно быстр. Кроме того, если что-то должно происходить постоянно, вы можете настроить агент, чтобы запускать его по расписанию. Одно дело написать его самостоятельно, но попытка сделать его многопоточным становится намного сложнее, чем кажется на первый взгляд.
Я бы рекомендовал SSIS 9 раз из десяти.
Я могу говорить только за себя и свой опыт. Я бы выбрал SSIS, поскольку это один из тех случаев, когда вы можете заново изобретать колесо без надобности. Это повторяющаяся задача, которая уже решена SSIS.
У меня около 57 рабочих мест (комбинация DTS и SSIS), которыми я управляю ежедневно. Четыре из них обычно занимаются экспортом от 5 до 100 миллионов записей. База данных, которой я управляю, содержит около 2 миллиардов строк. Я использовал задачу сценария, чтобы добавить дату с точностью до миллисекунды, чтобы я мог запускать задания несколько раз в день. Занимаюсь этим уже около 22 месяцев. Это было здорово!
Также можно запланировать задания SSIS. Так что вы можете установить его и забыть. Я слежу за всем каждый день, но часть работы с файлами никогда не ломалась.
Единственный раз, когда мне пришлось прибегнуть к специальной программе на C#, это когда мне нужно было разбить очень большие файлы на более мелкие части. SSIS медлителен для подобных вещей. На разделение текстового файла размером 1 гигабайт потребовалось около часа с использованием задачи сценария. Специальная программа C# справилась с этим за 12 минут.
В конце концов, просто используйте то, что вам удобно.
Вы только что создали для меня бизнес-кейс, который я должен передать моему руководителю по этому проекту. Вы унаследовали эти пакеты или создали их?
Я создал все с нуля. Это гигантский проект интеграции с системой электронного маркетинга сторонних поставщиков. Не стесняйтесь обращаться ко мне, если у вас есть еще вопросы по этому поводу.
Я не вижу, как использование нескольких потоков может повысить производительность в этом случае. При передаче больших объемов данных основным узким местом обычно является дисковый ввод-вывод. Создание нескольких потоков не решит эту проблему, и я предполагаю, что это только усугубит ситуацию, поскольку приведет к конфликту блокировок между несколькими процессами, обращающимися к базе данных.
Я ценю ответ Майка, и я обязательно приму его близко к сердцу, когда изучу это дальше. Это также будет повторяемый механизм, еще раз спасибо.