从我们的一位合作伙伴那里,我收到了大约 10.000 个小制表符分隔的文本文件,每个文件中包含 +/- 30 条记录。他们不可能把它放在一个大文件中。
我在 ForEach 循环容器中处理这些文件。读取文件后,执行 4 列推导,最后将内容存储在 SQL Server 2012 表中。
此过程最多可能需要两个小时。
我已经尝试将小文件处理成一个大文件,然后将这个文件导入同一个表中。这个过程需要更多的时间。
有没有人有任何建议来加快处理?
从我们的一位合作伙伴那里,我收到了大约 10.000 个小制表符分隔的文本文件,每个文件中包含 +/- 30 条记录。他们不可能把它放在一个大文件中。
我在 ForEach 循环容器中处理这些文件。读取文件后,执行 4 列推导,最后将内容存储在 SQL Server 2012 表中。
此过程最多可能需要两个小时。
我已经尝试将小文件处理成一个大文件,然后将这个文件导入同一个表中。这个过程需要更多的时间。
有没有人有任何建议来加快处理?
听起来违反直觉的一件事是用 4 替换您的一个派生列转换,并让每个执行一个任务。这可以提供性能改进的原因是,如果引擎可以确定这些更改是独立的,则它可以更好地并行化操作。
由于您正在引用远程服务器上的文件,因此您可能会遇到网络延迟。也许您可以通过在处理之前将这些远程文件复制到本地机器来提高性能。您感兴趣的性能计数器是
您可以做的另一件事是用行计数转换替换您的目标列和派生列。为所有文件运行几次包,这将决定您的理论最大速度。你将无法比这更快。然后添加您的派生列并重新运行。这应该可以帮助您了解性能下降是由于目标、派生列操作还是包运行速度与 IO 子系统一样快。
您的文件是否提供了一种简单的方法(即它们的名称)将它们细分为偶数(或大部分偶数)组?如果是这样,您可以并行运行负载。
例如,假设您可以将它们分成 4 组,每组 2,500 个文件。
如果文件本身不提供对它们进行分组的简单方法,请考虑在您的合作伙伴发送它们时将它们推入子文件夹,或者将文件路径插入数据库,以便您可以编写查询来细分它们并使用文件路径字段作为数据流任务中的变量。