2008-09-28 7 views
2

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

Можно ли использовать файл с миллионами записей с SSIS, или коллектив «вы» предпочитаете приложение aC# с несколькими рабочими потоками (один для чтения и добавления строки в переменную, один для записи из этой переменной к БД) и «материнский» класс, который управляет этими потоками? (Коробка Дев два процессора)

Я видел эти данные (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 

Каковы ваши мысли?

ответ

6

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

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

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

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

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

+0

Вы только что создали бизнес-кейс для меня, чтобы взять мой премьер-министр об этом проекте. Вы наследовали эти пакеты или создали их? – RyanKeeter 2008-09-28 21:50:21

1

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

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

+0

Я ценю ответ Майка, и я обязательно приму его, когда буду смотреть дальше. Это также будет повторяемым механизмом, спасибо еще раз. – RyanKeeter 2008-09-28 21:38:39

1

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