问题描述
嗨,我正在尝试通过使用JDBI的Java应用程序将来自Oracle 11的多个单独表的大量数据导出到NoSQL数据库中。
正在从以下表中读取数据: 商店,商店2,员工和产品。
最终期望的数据结构是类似于这样的多层结构;
将会有很多国家,每个国家可以有很多商店,每个商店可以有很多员工/产品。
到目前为止,我已经尝试通过使用光标表达式 (refcursor) 在结构中查询来自Oracle的数据来执行此导出,然后
在保存到新的NoSQL数据库之前,将结果映射到Java对象。
用于从Oracle提取数据的查询的非常简化的版本如下;
选择countryName,光标 (storeefloorsize,storeAddress1,storePostcode,光标 (从staff中选择staffForename,其中staff.storeId = store.Id),
光标 (从产品中选择productName,其中product.storeid = store.id)
从 (从商店联盟中选择 * 从商店2) 商店。countryid = 国家。id) 从国家
然而,由于数据量很大,这种方法有效,它需要很长时间 (几天才能完成),并且有一些限制。
整个过程需要两到三天的时间来完成,但是当查看Oracle stats时,在Oracle上执行的时间仅约为6小时 (请注意,查询完成时间为6小时,这对于数据量是有利的)。
到目前为止,在试图追踪这额外的时间在哪里,我已经完成/检查了以下内容;
1.首先,NoSQL数据库已完全从方程式中删除,并且性能保持不变。
2.在CPU和内存资源方面,运行Java应用程序的Oracle服务器和计算机都很好 (两台计算机上两种资源的使用率都很少)
3.我已经在多个线程上分解了任务,每个线程都在表的单独分区上工作 (在上面的示例中为国家); 每个线程执行从oracle中选择-> 映射到java对象-> 保存到NoSQL-在大量线程中进行的并行处理减少了Oracle上的执行时间,但对总体时间没有实际影响。(这些是Java中的单独线程,每个线程都有自己通过连接池与Oracle的单独连接)
4.我已经尝试修改fetchSize属性,但它似乎有一个非常小的差异 (这增加了另一个复杂性,因为每个结果行包含三个游标,并且在大量线程中并行运行时,Oracle上的MAX_OPEN_CURSORS设置需要非常快地急剧增加)。
我似乎无法识别任何特定的瓶颈,但是资源利用率仍然很低。
正如在第一行中提到的,我正在使用JDBC周围的JDBI包装器来执行查询并将结果映射到Java对象,但是如果这是瓶颈,我相信我会在运行Java应用程序的机器上看到高使用率。
有什么我可能忽略了上面的,或者Oracle设置,可能是相关的进一步调查,或者我可能更好地移回纯SQL查询并在Java中执行转换?
正在从以下表中读取数据: 商店,商店2,员工和产品。
最终期望的数据结构是类似于这样的多层结构;
Country Store1 StoreFloorSize StoreAddress1 StorePostcode StoreStaff StaffMember1 StaffForename StaffMember2 StaffForename StoreProducts Product1 ProductName Product2 ProductName Store2 ...复制
将会有很多国家,每个国家可以有很多商店,每个商店可以有很多员工/产品。
到目前为止,我已经尝试通过使用光标表达式 (refcursor) 在结构中查询来自Oracle的数据来执行此导出,然后
在保存到新的NoSQL数据库之前,将结果映射到Java对象。
用于从Oracle提取数据的查询的非常简化的版本如下;
选择countryName,光标 (storeefloorsize,storeAddress1,storePostcode,光标 (从staff中选择staffForename,其中staff.storeId = store.Id),
光标 (从产品中选择productName,其中product.storeid = store.id)
从 (从商店联盟中选择 * 从商店2) 商店。countryid = 国家。id) 从国家
然而,由于数据量很大,这种方法有效,它需要很长时间 (几天才能完成),并且有一些限制。
整个过程需要两到三天的时间来完成,但是当查看Oracle stats时,在Oracle上执行的时间仅约为6小时 (请注意,查询完成时间为6小时,这对于数据量是有利的)。
到目前为止,在试图追踪这额外的时间在哪里,我已经完成/检查了以下内容;
1.首先,NoSQL数据库已完全从方程式中删除,并且性能保持不变。
2.在CPU和内存资源方面,运行Java应用程序的Oracle服务器和计算机都很好 (两台计算机上两种资源的使用率都很少)
3.我已经在多个线程上分解了任务,每个线程都在表的单独分区上工作 (在上面的示例中为国家); 每个线程执行从oracle中选择-> 映射到java对象-> 保存到NoSQL-在大量线程中进行的并行处理减少了Oracle上的执行时间,但对总体时间没有实际影响。(这些是Java中的单独线程,每个线程都有自己通过连接池与Oracle的单独连接)
4.我已经尝试修改fetchSize属性,但它似乎有一个非常小的差异 (这增加了另一个复杂性,因为每个结果行包含三个游标,并且在大量线程中并行运行时,Oracle上的MAX_OPEN_CURSORS设置需要非常快地急剧增加)。
我似乎无法识别任何特定的瓶颈,但是资源利用率仍然很低。
正如在第一行中提到的,我正在使用JDBC周围的JDBI包装器来执行查询并将结果映射到Java对象,但是如果这是瓶颈,我相信我会在运行Java应用程序的机器上看到高使用率。
有什么我可能忽略了上面的,或者Oracle设置,可能是相关的进一步调查,或者我可能更好地移回纯SQL查询并在Java中执行转换?
专家解答
嗯,使用Java将关系数据从Oracle转换为NoSQL。听起来很痛苦;)
无论如何,如果在数据库中花费的时间只有6个小时,但是这个过程需要几天才能完成,那么您需要弄清楚应用程序在其他50个小时内正在做什么。
在你知道之前,你是在黑暗中射击。也许你会走运并找出问题所在。你更有可能继续调整影响很小或没有影响的事情。
端到端地配置整个应用程序。Dynatrace等产品可以为您提供帮助。
一旦你确定了时间的去向,你就可以开始弄清楚该改变什么了。
如果您在进行此分析后需要进一步的帮助,请发布您的发现,我们将拭目以待。
当然,更简单的解决方案可能是使用复制产品进行转换,例如GoldenGate:
http://www.oracle.com/us/products/middleware/data-integration/goldengate-for-big-data-ds-2415102.pdf
无论如何,如果在数据库中花费的时间只有6个小时,但是这个过程需要几天才能完成,那么您需要弄清楚应用程序在其他50个小时内正在做什么。
在你知道之前,你是在黑暗中射击。也许你会走运并找出问题所在。你更有可能继续调整影响很小或没有影响的事情。
端到端地配置整个应用程序。Dynatrace等产品可以为您提供帮助。
一旦你确定了时间的去向,你就可以开始弄清楚该改变什么了。
如果您在进行此分析后需要进一步的帮助,请发布您的发现,我们将拭目以待。
当然,更简单的解决方案可能是使用复制产品进行转换,例如GoldenGate:
http://www.oracle.com/us/products/middleware/data-integration/goldengate-for-big-data-ds-2415102.pdf
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。
评论
相关阅读
Oracle RAC 一键安装翻车?手把手教你如何排错!
Lucifer三思而后行
597次阅读
2025-04-15 17:24:06
【纯干货】Oracle 19C RU 19.27 发布,如何快速升级和安装?
Lucifer三思而后行
574次阅读
2025-04-18 14:18:38
XTTS跨版本迁移升级方案(11g to 19c RAC for Linux)
zwtian
488次阅读
2025-04-08 09:12:48
Oracle数据库一键巡检并生成HTML结果,免费脚本速来下载!
陈举超
474次阅读
2025-04-20 10:07:02
【ORACLE】记录一些ORACLE的merge into语句的BUG
DarkAthena
458次阅读
2025-04-22 00:20:37
Oracle 19c RAC更换IP实战,运维必看!
szrsu
434次阅读
2025-04-08 23:57:08
【ORACLE】你以为的真的是你以为的么?--ORA-38104: Columns referenced in the ON Clause cannot be updated
DarkAthena
433次阅读
2025-04-22 00:13:51
【活动】分享你的压箱底干货文档,三篇解锁进阶奖励!
墨天轮编辑部
419次阅读
2025-04-17 17:02:24
火焰图--分析复杂SQL执行计划的利器
听见风的声音
366次阅读
2025-04-17 09:30:30
3月“墨力原创作者计划”获奖名单公布
墨天轮编辑部
358次阅读
2025-04-15 14:48:05