我有一个数据转换产品,它允许在数据库中选择表并将源数据库中的行数据转换为目标数据库。如何处理任何数据库上的大量事务?
这是在当前产品(基于Java的工作台和引擎)中一次处理1000行并且并行执行10个线程处理的。这种方法适用于较小的数据集。但是,当我有能力改变庞大的数据集(说一下X万条记录)在同一时间 - 这种方法仍然有效,但
- 上我的产品上运行,是高负载下的主机的CPU。
- 源数据库和目标数据库被过多的事务打断,导致其开始放慢速度。 (现在,这可以归因于数据库服务器可能运行在较慢的硬件上)
我开始寻找解决方案,并且我很快就通过请求硬件“加强“在源/目标数据库服务器上。这涉及到购买新的多核CPU和一些额外的RAM。事实证明,升级硬件不仅仅是唯一的问题:需要购买数据库的多个软件许可证 - 这要归功于多核处理器(每个核心许可证)。
因此,球现在在我的球场上,我将不得不想出办法解决这个问题,通过改变我的产品。而且,这里是我需要你帮助的地方。在这一刻,我能想到的一个可能的方法来处理巨大的负荷:
Approach1从源数据库
- 读取数据时,它坚持到一个临时介质(文件)。
- 通过在分布式环境(更便宜的单核计算机)中运行,通过处理切换到文件持久性的“折衷方案”,将数据转换为持久化文件。 (使用Apache Hadoop之类的东西来处理分布式计算部分)
- 将数据写入目标数据库。
这是我现在所能想到的,从建筑的角度来看。 你以前是否处理过这种情况?如果是的话,你是怎么处理的? 感谢您的建议和帮助。
什么是性能瓶颈?你提到了两个候选人:应用程序CPU负载和数据库负载。你能进一步缩小它吗? – oksayt 2010-09-13 15:08:39
@oksayt现在,我主要关心的是数据库负载。我没有这方面的基准,但想法是通过考虑可能的瓶颈来构建更好的产品。 – Jay 2010-09-13 17:07:19