在将数百万条记录批量插入Oracle时,我遇到了一些性能问题。
因此,我运行了一些测试,试图了解创建实体的最佳方法。
我很好奇为什么使用休眠生成器比不使用要快。
方案:
1.(自动审核):使用envers和Hibernate生成器(uuid 2)
1.(审核随机):使用envers和UUID。随机UUID().toString()作为id
1.(审核随机选择锁定):使用envers和UUID.randomUUID().toString()作为id,并使用Sping Boot @Version作为乐观锁定
1.(无自动审计):没有envers和Hibernate生成器(uuid 2)
1.(无审计随机):没有envers和UUID。随机UUID().toString()作为id
1.(无稽核随机OptLock):没有envers和UUID。随机UUID().toString()作为ID,Sping Boot @Version用于乐观锁定
所有实体都是具有两列的简单实体。
实体:ID varchar 2(255)主键,名称varchar 2(255)
结果为1.000.000条记录:
创建集合:
1.自动审核::192毫秒
1.审计随机:1125毫秒
1.审计随机选择锁定::646毫秒
1.无自动审核::16毫秒
1.无审计随机::1694毫秒
1.无审计随机选择锁定::841毫秒
在这里,一切都如预期:使用UUID.randomUUID()创建实体集合的速度比不使用要慢,原因很明显。
保存集合(每个集合在其自己的事务中)
1.审核自动存储库::小行星216847
1.审核随机存储库::小行星338461
1.审核随机OptLock存储库::370750毫秒
1.无审计自动存储库::小行星88616
1.无审计随机存储库::155202毫秒
1.无审核随机OptLock存储库::176575毫秒
这里是我不明白的地方。好吧...使用envers比不使用(这是预期的)要慢(1,2和3)。但是我不明白为什么使用hib生成器在保存(和提交)时更快。
由于在使用UUID.randomUUID()时已经在实体上设置了id,而使用生成器时却没有,我希望场景5和6比4快,但事实并非如此。可能是因为传输的数据量太大了吧?
我运行了很多次scearios,我得到了一致的结果。
我想听听你对这件事的看法。
(Guys,问题不在于我是否需要envers的业务规则,而在于在批量插入中如何处理事情的技术好奇心)。
- 谢谢-谢谢
使用环境:Oracle第12版c| Oracle JDK 1.8版本| Spring Boot 1.5.4|休眠5.4
1条答案
按热度按时间u7up0aaq1#
我找到的答案是:
根据您执行批插入的方式,Hibernate不仅执行插入,还执行其他SQL。
关于我最初的问题,关于我期望5和6更快。我是对的和错的。
场景5不应该更快,因为它在插入之前执行SELECT。
场景6被认为是更快的,因为它只执行了一次插入,没有其他操作。然后问题是,对于乐观锁,我使用的是来自spring的@Version,这个并没有告诉Hibernate实体是否是持久的。所以,和场景5一样,它确实在之前执行了一个SELECT。
应该从javax. persistence导入@版本以正确执行此操作。
下面列出了queires hib在每个场景中的执行情况,以及使用正确的@Version所花费的正确时间(对于100万条记录)。
1.(自动审核):使用envers和Hibernate生成器(uuid 2)
2.(审核随机):使用envers和UUID。随机UUID().toString()作为id
3.(审核随机选项锁定):使用envers和UUID.randomUUID().toString()作为ID,并使用Sping Boot @Version作为乐观锁定
4.(无自动审计):不带envers和Hibernate生成器(uuid 2)
5.(无审计随机):没有envers和UUID。随机UUID().toString()作为id
6.(无审计随机OptLock):没有envers和UUID。随机UUID().toString()作为ID,Sping Boot @Version用于乐观锁定
创建集合:
1.自动审核::174毫秒
1.审计随机:902毫秒
1.审计随机选择锁定::778毫秒
1.无自动审核::18毫秒
1.无审计随机::1584毫秒
1.无审计随机选择锁定::808毫秒
保存集合(每个集合在其自己的事务中)
1.自动审核::355222毫秒
1.审核随机::350674毫秒
1.审核随机选择锁定::小行星385234
1.无自动审核::小行星114813
1.无审计随机::小行星119246
1.无审计随机选择锁定::小行星74858