bcp / BULK INSERT与表值参数的性能

我将不得不使用SQL Server的BULK INSERT命令重写一些相当老的代码,因为架构已经改变了,而且我想到了也许我应该考虑用TVP切换到存储过程,但是我想知道它可能对性能有什么影响。

一些背景信息可能有助于解释为什么我问这个问题:

  • 数据实际上是通过Web服务进入的。 Web服务将文本文件写入数据库服务器上的共享文件夹,然后执行BULK INSERT 。 这个过程最初是在SQL Server 2000上实现的,当时真的没有别的办法,只能在服务器上夹几百个INSERT语句,这实际上是原来的过程,并且是性能灾难。

  • 数据被批量插入到永久登台表中,然后被合并到一个更大的表中(之后,它从登台表中被删除)。

  • 要插入的数据量是“大”,但不是“巨大” – 通常是几百行,在极less数情况下可能是5-10k行。 因此,我的直觉是BULK INSERT是一个非日志操作,不会太大的区别(当然,我不确定,因此是个问题)。

  • 插入实际上是一个更大的stream水线批处理的一部分,需要连续发生多次; 因此性能至关重要。

我想用TVP取代BULK INSERT的原因是:

  • 通过NetBIOS编写文本文件可能已经花费了一些时间,从架构的angular度来看这是相当可怕的。

  • 我相信舞台表可以(也应该)被淘汰。 主要原因是插入的数据需要在插入的同时用于其他更新,并且从大量生产表尝试更新比使用几乎空的暂存更昂贵表。 有了TVP,参数基本上就是临时表,我可以在主插入之前/之后做任何事情。

  • 我几乎可以避免使用重复检查,清除代码以及所有与批量插入相关的开销。

  • 如果服务器同时获取这些事务中的一些(我们试图避免它,但是它发生),则无需担心登台表或tempdb上的锁争用。

很明显,在将任何东西投入生产之前,我会先简单介绍一下,但是我认为在我花费所有时间之前先问问一下是个好主意,看看有没有人有严格的警告要求使用TVP来达到这个目的。

所以 – 对于那些对SQL Server 2008来说足够安逸的人来说,已经尝试过或者至less调查过这个,那么判断是什么? 对于插入数百行到数千行,频繁发生的事情,TVP是否切断了芥末? 与散装刀片相比,性能是否有显着差异?


更新:现在减less了92%的问号!

(又名:testing结果)

现在最终的结果是在36阶段的部署过程之后进行生产。 两种解决scheme都经过了广泛的testing

  • 翻出共享文件夹代码并直接使用SqlBulkCopy类;
  • 使用TVP切换到存储过程。

为了让读者能够了解究竟是什么被testing的,为了消除对这些数据的可靠性的任何怀疑,下面是对这个导入过程实际上做了什么的更详细的解释:

  1. 从一个通常约20-50个数据点的时间数据序列开始(尽pipe有时可能多达几百个);

  2. 做一大堆疯狂的处理,大部分独立于数据库。 这个过程是并行的,所以(1)中的大约8-10个序列正在被同时处理。 每个并行进程生成3个附加序列。

  3. 把所有3个序列和原始序列合并成一个批次。

  4. 将所有8-10个已完成的加工任务的批次合并为一个大的超批次。

  5. 使用BULK INSERT策略(见下一步)或TVP策略(跳到步骤8)导入它。

  6. 使用SqlBulkCopy类将整个超批量转储到4个永久登台表中。

  7. 运行一个存储过程(a)在其中两个表上执行一系列聚合步骤,包括几个JOIN条件,然后(b)使用聚合数据和非聚合数据在6个生产表上执行MERGE 。 (成品)

    要么

  8. 生成包含要合并的数据的4个DataTable对象; 其中3个包含CLRtypes,不幸的是ADO.NET TVPs不能很好地支持这种types的CLRtypes,所以它们不得不作为stringexpression式来使用,这会使性能稍微受损。

  9. 将TVP提供给一个存储过程,它执行与(7)基本相同的处理,但直接与接收的表进行交互。 (成品)

结果是相当接近的,但是即使数据超过1000行less量,TVP方法的平均performance也最好。

请注意,这个导入过程连续运行了上千次,所以只需要计算完成所有合并所花费的时间(是,小时)就可以很容易地获得平均时间。

最初,平均合并花费了将近8秒完成(在正常负载下)。 删除NetBIOS kludge并切换到SqlBulkCopy减less了几乎7秒的时间。 切换到TVP进一步减less了每批5.2秒的时间。 对于运行时间以小时为单位的stream程来说,吞吐量提高35% – 所以一点也不差。 与SqlBulkCopy相比,这也有了25%的提升。

我确实相当确信,真正的改善远远超过这个。 在testing过程中,显然最终的合并不再是关键path。 相反,正在进行所有数据处理的Web服务在进入的请求数量下开始出现问题.CPU和数据库I / O都没有真正被刷新,并且没有显着的locking活动。 在某些情况下,我们在连续合并之间看到了一些空闲时间的差距。 使用SqlBulkCopy时有一个小小的差距,但要小得多(半秒左右)。 但我想这将成为另一天的故事。

结论: 对于在中型数据集上运行的复杂导入+转换过程,表值参数确实比BULK INSERT操作性能更好。


我想补充一点,只是为了减轻对亲台的一部分人的担忧。 从某种意义上说,这整个服务是一个巨大的分期过程。 该stream程的每一步都经过严格审核,因此我们不需要临时表来确定为什么某些特定的合并失败(尽pipe在实践中几乎从不发生)。 我们所要做的就是在服务中设置一个debugging标志,它将打断debugging器或将其数据转储到文件而不是数据库。

换句话说,我们已经对stream程有了足够的了解,并且不需要临时表的安全; 我们暂存表的首要原因是为了避免在所有INSERTUPDATE语句上出现颠倒,否则我们不得不使用这些语句。 在原始进程中,登台数据只能在临时表中生活几分之一秒,因此在维护/可维护性方面没有任何价值。

另外请注意,我们还没有用TVPsreplace每一个BULK INSERT操作。 处理大量数据和/或不需要对数据做任何特殊处理的几个操作,除了将其扔到数据库之外,仍然使用SqlBulkCopy我并不是说TVPs是一个performance灵丹妙药,只是在这个特定的例子中,他们成功地通过了SqlBulkCopy ,涉及到初始分段和最终合并之间的几个转换。

所以你有它。 点去TTonifind最相关的链接,但我也赞赏其他答复。 再次感谢!

4 Solutions collect form web for “bcp / BULK INSERT与表值参数的性能”

我还没有真正的TVP经验,但是在这里 MSDN有一个很好的性能比较图表和BULK INSERT。

他们说,BULK INSERT的启动成本更高,但之后更快。 在远程客户端场景中,他们绘制了大约1000行(对于“简单”服务器逻辑)。 从他们的描述来看,我会说你使用TVP应该没问题。 性能受到影响 – 如果有的话 – 可能可以忽略不计,build筑效益看起来非常好。

编辑:在旁边注意您可以避免服务器本地文件,并仍然使用SqlBulkCopy对象使用批量复制。 只需填充一个DataTable,并将其提供给“WriteToServer” – 一个SqlBulkCopy实例的方法。 易于使用,速度非常快。

我想我仍然坚持使用批量插入的方法。 您可能会发现tempdb仍然使用具有合理行数的TVP命中。 这是我的直觉,我不能说我testing了使用TVP的performance(虽然我也有兴趣听到别人的意见)

你没有提到你是否使用了.NET,但是我采用的方法来优化以前的解决scheme是使用SqlBulkCopy类来完成大量的数据加载 – 你不需要先把数据写入文件加载,只要给SqlBulkCopy类(例如)一个DataTable – 这是插入数据到数据库的最快方式。 5-10K行并不多,我已经用了750K行。 我怀疑,一般来说,有几百行,使用TVP不会有太大的区别。 但扩大规模将是有限的恕我直言。

也许SQL 2008中新的MERGEfunction会使你受益?

另外,如果现有的登台表是一个用于此进程的每个实例的单个表,并且您担心争用等问题,是否考虑每次都创build一个新的“临时”但是物理登台表,然后在完成了?

请注意,您可以优化加载到此临时表,通过填充它没有任何索引。 然后一旦填充,在这一点上添加任何所需的索引(FILLFACTOR = 100为最佳的读取性能,因为在这一点上它不会被更新)。

关于@Toni的回答中提到的链接的图表需要在上下文中进行。 我不确定这些build议有多less实际的研究(还要注意图表似乎只在该文档的20082008 R2版本中可用)。

另一方面,SQL Server客户咨询团队发布了这个白皮书: 通过TVP最大化吞吐量

自2009年以来,我一直在使用TVP,至less以我的经验发现,除了简单地插入到目标表中而没有额外的逻辑需求(很less有这种情况),TVP通常是更好的select。

我倾向于避免登台,因为数据validation应该在应用层完成。 通过使用TVP,这很容易被容纳,并且存储过程中的TVP表variables本质上是一个本地化的登台表(因此与使用真实表进行登台时得到的其他进程不会同时运行) )。

关于在这个问题上所做的testing,我认为它可能比最初发现的更快:

  1. 您不应该使用DataTable,除非您的应用程序在将值发送到TVP之外使用它。 使用IEnumerable<SqlDataRecord>接口速度更快,占用的内存也更less,因为不会将内存中的集合复制到数据库中。 我有这样的logging在下列地方:
    • 如何在最短的时间内插入1000万条logging? (很多额外的信息和链接在这里以及)
    • 将Dictionary <string,int>传递给存储过程T-SQL
    • 从应用程序将数据stream式传输到SQL Server 2008 (在SQLServerCentral.com上;需要免费注册)
  2. TVP是表variables,因此不保留统计。 意思是,他们只向查询优化器报告1行。 所以,在你的过程中,要么:
    • 对任何使用TVP的查询使用语句级重新编译,除了一个简单的SELECT: OPTION (RECOMPILE)
    • 创build一个本地临时表(即单个# ),并将TVP的内容复制到临时表中

舞台表很好! 真的,我不想做任何其他的方式。 为什么? 因为数据导入可能会意外地发生变化(通常情况下,您无法预见到的情况,比如列名仍然被称为名字和姓氏,但在姓氏列中包含名字数据,例如,随便。)易于研究与登台表问题,所以你可以看到什么数据是在导入处理的列。 当你在内存表中使用时,很难find我想的。 我知道很多人为了生活而import,所有人都推荐使用登台表。 我怀疑这是有原因的。

进一步修改小的模式更改到工作过程比重新devise过程更容易,更省时。 如果它正在工作,而且没有人愿意花费几个小时来改变它,那么只需要修改由于模式改变而需要修改的东西。 通过改变整个过程,与通过对现有的经过testing的工作stream程进行小的改变相比,您会引入更多潜在的新bug。

而且,你将如何解决所有的数据清理任务? 你可能会以不同的方式做,但仍然需要完成。 再一次地,按照你描述的方式来改变这个过程是非常危险的。

就我个人而言,听起来像刚刚使用旧技术而不是冒险玩新玩具, 你似乎没有真正的基础想要改变,除了批量插入是如此2000年。

  • 什么时候写“ad hoc sql”vs存储过程比较好?
  • SQL Server代理服务的凭据无效
  • 删除后续空格和SQL Server中的列中的更新
  • SQL Server添加新列后无效的列名称
  • 如何在一个SQL语句中获取varchar 字段的大小?
  • SQL Server SELECT最后N行
  • 检索存储过程结果集的列定义
  • 如何添加一个新的模式到SQL Server 2008?
  • 如何select列值不相同的每一行
  • 改变列,添加默认约束
  • 有没有办法在SELECT语句中访问“上一行”值?