处理任何数据库上的大型事务的方法？

Question

我有一个数据转换产品，它允许在数据库中选择表，并将源数据库中的行数据转换为目标数据库。

这是在当前产品(基于java的工作台和引擎)中通过一次处理1000行并并行执行10个线程来处理的。这种方法适用于较小的数据集。但是，当我不得不一次转换巨大的数据集(比如大约X百万条记录)时，这种方法仍然有效，但是

运行我产品的主机的CPU --

• --负载很重。源数据库和目标数据库
• 受到太多事务的冲击，它们开始减慢速度。(现在，这可以归因于数据库服务器可能运行在较慢的硬件上。)

。

我开始寻找解决方案，我很快就在源/目标数据库服务器机器上请求硬件“增强”来解决这个问题。这包括，比如说，购买一个新的多核CPU和一些额外的RAM.事实证明，升级硬件并不是唯一的问题:需要为数据库购买多个软件许可证--这要归功于多核处理器(每个核心许可证)。

所以，球现在在我的领域，我将不得不想出解决这个问题的方法，通过改变我的产品。这就是我需要你帮忙的地方。此时此刻，我可以想到一种可能的方法来处理巨大的负载：

Approach1

从源数据库读取数据，将其保存到持久化文件中的临时介质(file).

• Transform数据，在分布式环境中运行数据(更便宜的单核计算机)，在那里处理切换到文件持久性的“权衡移动”。(使用类似Apache的方法将分布式计算part)

• Writing数据处理到目标数据库。

从架构的角度来看，这是我目前所能想到的全部。你以前处理过这种情况吗？如果是的话，你是怎么处理的？感谢你的建议和帮助。

Answer 1

在不增加数据库许可证成本的情况下，您可以做几件事：

• 您的工具将CPU置于沉重的负荷之下，假设您的工具运行在一台没有运行数据库的机器上，增加该机器上的CPU能力，或者如果您的工具允许它在多台计算机上运行，则
• 是活动事务数量增加的原因之一，原因之一是每一个事务都需要时间来完成。您可以通过优化磁盘或放入更快的磁盘来加快速度。

另外，如果您使用的是insert而不是批量插入，则有很大的改进潜力。普通插入的问题是，它将信息写入日志，以便能够回滚事务。

在this的情况下，我能够帮助某人将负载时间从10小时减少到6 minutes :)

Answer 2

分而治之！

如果源DB不能同时处理两个作业( ETL和“常规”事务)，那么不要让它受到影响：

• 将源数据复制到“镜像”。
• 在“镜像”上执行ETL。

注:当我说“镜像”时，我只是指允许快速高效地复制数据的副本(有点像“暂存”DB) --而不是另一个大/慢/讨厌的ETL进程。这里的想法是优化流程以使源DB受益。

然后，您可以将ETL优化到目标DB，以使目标DB受益；因为您已经将源和目标分开，因此将更容易优化覆盖进程的读/插入部分。

您可能也可以在目标端执行类似的操作(使用另一个“镜像”/暂存DB)。

这种方法与您所建议的没有什么不同，但我假设在两个相同的数据库之间直接复制数据时，相同类型的将是最容易管理的，也是最有效的。

在此之后，您可以开始应用其他一些建议，其他人可以提出。

最后一件事--你可以尝试使用ETL工具--如果你在运行

Answer 3

这里要考虑的第一件事是，如果您真的需要为这么多的数据进行事务处理。如果答案是否定的，则您的数据库产品可能有一个批量插入选项，用于这种大型数据库插入。

编辑(进一步注释)：我认为(无论如何，在Server中)最棒的是在操作期间将目标数据库设置为简单的恢复模式。事实上，如果您这样做，很可能您将不必进行任何其他代码更改。

但是，只有当目标数据库没有同时用于其他事情时，这才是合适的。我想说，这是一项基本要求。在数据库中使用OLAP事务时，尝试将2500万条记录插入数据库是一个根本的数据库错误。如果这是绝对必要的，那么我认为解决方案是使进程非常慢(有大量的暂停)，以便释放资源，以便数据库能够继续运行。