【问题标题】:Slowness in reading the large ResultSet读取大型 ResultSet 的速度很慢
【发布时间】:2014-12-17 01:46:48
【问题描述】:

我在生成报告时遇到问题,结果超过 500,000 行。相信我,这个结果已经被过滤了。 查询 (DB2) 几乎立即运行,但结果集中的交互速度慢得离谱。

我正在做几个测试来尝试改进这个过程,但到目前为止都没有成功。 - 起初是为 bean 转换直接数据(用于生成报告),但速度很慢并且数据库超时。 - 我试图变成一个更简单的测试过程(resultSet to HashMap)不成功 - 对语句使用 setFetchSize 配置 (2000) - 我查看了使用线程安全的可能性,但不支持结果集

已经修改了银行的超时时间来增加处理时间,但是我的问题没有解决。

无论如何,已经尝试了几种可能性。有人对我的问题有任何提示或解决方案吗?

【问题讨论】:

  • 需要多长时间? 500,000 行是很多数据...
  • 换句话说,您正试图在 Java 中处理 500K 行。您应该找到一种在数据库中处理它们的方法。
  • 我们需要更多详细信息,例如您尝试运行的代码。不过,我支持 mustaccio - 将这么多行放入 Java 中会遇到问题。

标签: java performance db2 resultset c3p0


【解决方案1】:

首先让我澄清一下, 报告、报告生成任务永远不应该在应用程序数据库上完成。

应用程序数据库,事务数据库是为不涉及繁重的结果获取和处理的快速事务而设计的。这些任务应该在 DW 服务器或备用副本上处理。

第二,

报告应用程序逻辑应在不那么拥挤的时间处理(当用户不使用系统时,即晚上)

  1. 如果可能,将您的处理逻辑以过程(数学部分)的形式放在数据库端,并使用高效的查询来提高处理和数据传输方面的性能。
  2. 尝试使用触发器/计划作业等定期收集报告,并在创建报告时使用这些中间报告而不是 DB(正如您所说,您的查询执行不是问题,但这将节省对大集合的迭代。)您可以使用中间报告中的值,因此迭代频率会更少。

【讨论】:

  • ...这个划分实际上更多是与不同的表相关,尽管单独的物理框肯定会有所帮助。虽然看起来数据库本身不太可能是问题,但并不完全清楚 OP 在做什么。据我们所知,无论如何,他可能正在执行接触报告数据库的过程。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-10-03
  • 1970-01-01
相关资源
最近更新 更多