2

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

最好使用 SSIS 运行具有数百万条记录的平面文件，还是集体“你”更喜欢具有多个工作线程的 ac# 应用程序（一个用于读取行并将行添加到变量，一个用于从该变量写入数据库） ，以及管理这些线程的“母亲”类？（开发盒有两个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

你怎么认为？

4

3 回答 3

6

我只能代表我自己和我的经历。我会选择 SSIS，因为这是您可能不必要地重新发明轮子的情况之一。这是 SSIS 已经解决的重复性任务。

我每天管理大约 57 个工作（DTS 和 SSIS 的组合）。其中四个通常处理 5 到 1 亿条记录的导出。我管理的数据库有大约 20 亿行。我使用了一个脚本任务来追加日期，精确到毫秒，这样我就可以一天运行几次作业。现在已经这样做了大约 22 个月。太棒了！

也可以安排 SSIS 作业。所以你可以设置它并忘记它。我每天都会监控一切，但文件处理部分从未发生过故障。

唯一一次我不得不求助于自定义 C# 程序，是当我需要将非常大的文件拆分成更小的块时。SSIS 对这类东西很慢。使用脚本任务拆分一个演出文本文件大约需要一小时。C# 自定义程序在 12 分钟内处理了这个问题。

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

于 2008-09-28T21:16:02.657 回答
1

SSIS 非常快。此外，如果需要重复发生某些事情，您可以设置一个代理以按时将其触发。自己编写是一回事，尝试使其多线程变得比最初看起来要复杂得多。

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

于 2008-09-28T21:13:29.903 回答
1

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

于 2008-09-28T21:16:39.550 回答