多线程& 数据库记录锁

发布于 2024-07-29 13:26:36 字数 418 浏览 8 评论 0原文

需要很大的帮助......

我需要创建一个 .net 应用程序，它将对表中的大约 2,000,000 条记录执行一些批量操作。应用程序应该运行并尝试处理尽可能多的行。我在想，如果我可以让应用程序的多个线程一次获取 2000 条记录，处理它们，它应该能够处理更多。然而，这对数据库服务器来说将是相当昂贵的。据我所知，数据库服务器是一台强大的机器，应该能够承受压力。

此外，由于一次仅获取 2000 行，如果应用程序在处理过程中终止，它会知道从哪里再次获取。

所以，我想我要问的是......

1）我怎样才能让应用程序拾取行和行？锁定这些行以便它不会被分配给另一个线程？

2) 什么样的智能可以被编程到应用程序中，使其能够从上次中断的地方继续处理？

谢谢

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

朦胧时间 2024-08-05 13:26:36

您应该使用 SQL Server Integration Services (SSIS) 来完成此操作，而不是重新发明轮子。它针对这些场景进行了高度优化，特别是在 2008 年版本中。

回复收藏 0 原文

遥远的她 2024-08-05 13:26:36

我同意 John 的观点，即 SSIS 对于此类场景有很多内置智能，并且可能是投入时间的最佳选择。

作为记录，您可以通过对数据进行分区来解决此类问题。我不是在谈论物理存储分区（即添加表分区），而是逻辑处理分区。你分配你的200万。 N 个分区中的记录，基于您拥有的可以在数据访问级别利用的任何标准，例如。一个索引列，然后分配 N 个处理器，每个处理器开始在自己的分区上进行搅动。这个想法是避免处理器在尝试访问相同的行时重叠。 “处理器”可以是线程，或者更好的是使用异步数据库访问方法的 ThreadPool 排队工作项。

最大的问题是很多时候你没有合适的分区键。在这种情况下，您可以执行如下所示的临时分区：

with cte as (
   select top (@batchSize) *
   from myTable with (rowlock, updlock, readpast)
   where <record is ready to be processed>)
update cte
   set <mark record processing>
output inserted.*

技巧是 select 中使用的锁定提示：通过强制和 updlock，记录被锁定以供当前处理器处理。通过添加 readpast 提示，每个处理器将跳过已被其他处理器锁定的记录。这样，无论处理是什么，每个处理器都会获得自己的 @batchSize 批次记录来处理。

重要的是要理解，所有这些注释都适用于涉及数据库外部的处理，例如进行 Web 服务调用、打印纸条或类似的操作。如果处理全部在数据库中，那么您应该将其表示为单个 T-SQL 更新，并让查询优化器根据需要使用并行查询。

I agree with John that SSIS has a lot of built in intelligence for such scenarios and is probably the best bet to invest your time into.

For the record such problems you approach by partitioning your data. I'm not talking about the physical storage partitioning (ie. add table partitioning), but logical, processing partitioning. You partition your 2 mil. records in N partitions, based on whatever criteria you have that can be exploited at the data access level, eg. an indexed column, then allocate N processors that start churning each on its own partition. The idea is to not have the processors overlap in trying to access the same rows. 'Processors' can be threads, or better still ThreadPool queued up worker items that use async database access methods.

The big problem is that many times you don't have a suitable partitioning key. In such cases you can do an ad-hoc partitioning like this:

with cte as (
   select top (@batchSize) *
   from myTable with (rowlock, updlock, readpast)
   where <record is ready to be processed>)
update cte
   set <mark record processing>
output inserted.*

The trick is the locking hints used in the select: by forcing and updlock the records are locked for processing by the current processor. By adding the readpast hint each processor will skip records that are already locked by other processors. This way each processor gets its own @batchSize batch of records to process, whatever the processing is.

Important to understand that all these comments apply to a processing that involves something outside the database, like doing a web service call, printing a paper slip or anything similar. If the processing is all in the database, then you should just express it as a single T-SQL update and let the query optimizer use parallel queries it as it sees fit.

回复收藏 0 原文