我应该使用SSIS或多线程C#应用程序将平面文件加载到数据库中吗？

Question

在SQL Server Integration Services (SSIS)中，可以设置到可容纳数百万条记录的平面文件的连接，并将这些数据推送到SQL DB。此外，可以通过引用和使用Microsoft.SqlServer.Dts.Runtime名称空间从C#应用程序调用此流程。

一个包含数百万条记录的平面文件最好与SSIS一起运行，还是集体“您”更喜欢有多个工作线程的c#应用程序(一个线程读取变量并将行添加到变量，另一个线程将行从变量写入数据库)和管理这些线程的“母”类？( dev box有两个cpu)

我看到这个数据(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的组合)。其中四个通常处理500万到1亿条记录的导出。我管理的数据库大约有20亿行。我使用了一个脚本任务来追加日期，精确到毫秒，这样我一天就可以运行几次作业。现在已经做了大约22个月了。太棒了！

还可以安排SSIS作业。因此，您可以设置它，然后忘记它。我每天都在监控一切，但文件处理部分从来没有出过故障。

我唯一不得不求助于定制C#程序的时候，就是我需要将非常大的文件分成更小的块的时候。SSIS对于这类东西来说是很慢的。使用脚本任务，一个gig文本文件需要大约一个小时才能拆分。C#定制程序在12分钟内就处理完了这个问题。

最后，只使用你觉得舒服的东西。

Answer 2

SSIS的速度令人难以置信。此外，如果它需要重复发生，您可以设置一个代理来按计划启动它。自己编写它是一回事，试图让它多线程变得比最初看起来复杂得多。

我会推荐SSIS十次中的九次。

Answer 3

在这种情况下，我看不出使用多线程会对性能有什么帮助。在传输大量数据时，主要的瓶颈通常是磁盘I/O。派生多个线程不会解决这个问题，我的猜测是它会使事情变得更糟，因为它会在访问数据库的多个进程之间引入锁定争用。