【java】itoo项目实战之hibernate 批量保存优化

在itoo中。基本上每一个系统都有一个导入功能,大量的数据填写进入excel模板中。然后使用导入功能导入的数据库中,这样能够大大的提高工作效率。

那么导入就涉及到了批量保存数据库的问题了。

那么通常情况下,在一个Session对象的缓存中数量有限的持久化对象,等到Session对象处理事务完成,还要关闭Session对象,从而及时释放session的缓存占用的内存。在批量保存1万条数据,假设一次性把须要保存的1万条数据载入到内存职工,当运行事务提交的时候,就会清理缓存,hibernate运行1万条更新语句。

这样更新的方式有两个缺点:

(1)占用大量内存。必须把1万条载入到内存中,然后一一更新它们。

(2)运行的update数目过多,每一个update语句仅仅能更新一条数据,必须通过1万条update语句才干更新1万条数据。频繁地訪问数据库,会大大减少应用的性能。

对于以上的情况。咱们能够通过Session来进行批量操作。Session
的sava方法都会把处理对象的存放在自己的缓存职工,假设通过一个Session对象来处理大量持久化对象,应该及时从缓存中清空已经处理完成而且不会在訪问的对象。

详细的做法就是处理完一个对象或者小批量对象后,立马调用Flush()方法清理缓存,然后再调用Clear()方法清空缓存。

假设通过Session来进行批量操作,会受到下面的约束:

1.须要在hibernate的配置文件里设置JDBC单次批量处理的数目。合理的取值通常为10~50,比如hibernate.jdbc.batch_size=30;这样设置的。就须要保证每次像数据库发送的批量SQL语句数目与这个batch_size属性一致。

2.假设操作对象採用"identity"标识符生成器,则Hibernate无法在JDBC层进行批量插入操作。

3.进行批量操作时。建议关闭hibernate的第二级缓存。Session的缓存为hibernate的第一级缓存,通常它是事务范围内的缓存。每一个事务都有单独的第一级缓存。

SessionFactory的外置缓存为Hibernate的第二级荤菜,它是应用范围内的缓存,全部的事务都共享同一个第二级缓存。在不论什么情况下,hibernate的第一级缓存总是可用的,在默认情况下。hibernate的第二级缓存是关闭的。可是也能够在hibernate的配置文件里手动关闭二级缓存:

Hibernate.cache.use_second_level_cache=false;

在itoo中批量保存的代码例如以下:

<span style="font-family:FangSong_GB2312;font-size:18px;">/**
 * 批量保存
 *
 * @param list
 *            list类型
 * @return 返回boolean值
 */
public <T> boolean saveEntitys(List<T> list) {
boolean flag = false;
int batchSize = 30;
int i = 0;
getDataBaseName(list.get(0));
try {
for (Object entity : list) {
getEntityManager().persist(entity);
i++;
if (i % batchSize == 0) {
getEntityManager().flush();
getEntityManager().clear();
}
}
flag = true;
} catch (Exception e) {

}
return flag;
}</span>

在以上的程序中,每次运行session.flush()方法,就会向数据库职工批量插入30条记录。接下来session.clear()方法把20个刚保存的对象从缓存中清空。

仅仅要是设计有批量导入的情况,都会涉及到批量保存的内容,这篇博客就是让你的批量保存达到最优效果。

时间: 2025-01-11 06:15:42

【java】itoo项目实战之hibernate 批量保存优化的相关文章

【java】itoo项目实战之hibernate 懒载入优化性能

在做itoo 3.0 的时候,考评系统想要上线,就開始导入数据了,仅仅导入学生2万条数据,可是导入的速度特别的慢.这个慢的原因是由于导入的时候进行了过多的IO操作.可是导入成功之后,查询学生的速度更加慢.由于底层用了hibernate的hql语句进行查询的,学习过hibernate的人都知道,假设hibernate不设置懒载入的话,仅仅有是有关联的数据都会一次性所有都查询出来,我试了试.查询2万条数据,最深的级联查询是有5层,然后发出来的语句是460条,时间大概是10s.然后就考虑使用lazy进

【java】itoo项目实战之hibernate 懒加载优化性能

在做itoo 3.0 的时候,考评系统想要上线,就开始导入数据了,只导入学生2万条数据,但是导入的速度特别的慢,这个慢的原因是因为导入的时候进行了过多的IO操作.但是导入成功之后,查询学生的速度更加慢,因为底层用了hibernate的hql语句进行查询的,学习过hibernate的人都知道,如果hibernate不设置懒加载的话,只有是有关联的数据都会一次性全部都查询出来,我试了试,查询2万条数据,最深的级联查询是有5层,然后发出来的语句是460条,时间大概是10s.然后就考虑使用lazy进行优

【java】itoo项目实战之大数据查询之使用 new map 优化hibernate之级联查询

在我的上一篇博客<[java]itoo项目实战之hibernate 懒加载优化性能>中,我曾提到过学生数据有2万条,查询数据十分的慢,这是让人很受不了的事情,看着页面进度条一直转着圈圈,那种着急的感觉真的没法形容.最开始考虑着使用lazy 来优化,因为前台框架的原因,lazy 优化并没有起到什么左右,后来就想着有select new map 优化.我先来画画关于查询学生的级联树 这个树的意思就是查询学生的时候它的深度是4级. 在没有优化之前,使用的是hibernate的hql 语句:From

【java】itoo项目实战之优化后具体代码

在我的前一篇博客中<<itoo项目实战之减少IO读写的导入思路>>,我介绍了如何完成减少IO读写的Excel导入,在这里我就把具体的代码实现分享给大家: 我就按照这张图的顺序给大家分享. 检查Excel 数据是否重复的代码: <span style="font-family:Times New Roman;font-size:18px;">// 2.从指定列中寻找重复行 for (int i = 1; i < realRows - 1; i++

Java Drp项目实战——Drp知多少

是什么 Drp是Distribution Resource Planning的缩写,意思是分销资源计划,它是用来管理企业的运行于Internet上的分销网络的系统,是以商业流程优化为基础,它的核心是销售和库存总和控制.这个分销系统或者说是分销体系,它的使用者包括一个大型企业的内部.各个分公司.各级分销商等,它的作用就在于即时的掌握各地的销售信息流.财务资金流.库存信息等一些功能. 产生背景是什么 知道了Drp是什么,我们还需要了解下它的开发背景是什么,为什么要开发这样的一个系统呢. 这个原因还是

JAVA Drp项目实战—— Unable to compile class for JSP 一波三折

交代下背景,电脑系统是64位的,用的是64位的Tomcat,安装是32位的Myeclipse10,java环境也是32位的,Tomcat在开始启动时会报这样一个错误,"Can't load IA 64-bit .dll on a AMD32-bit platform",但是不耽误使用,最近在敲Drp项目中用到了底层接口的几个方法,这个错误导致项目不能正常运行了,所以就将64位的Tomcat换成了与java环境一样的32位的Tomcat,上面的问题就顺利解决了,于是继续自己的开发,但是当

【java】itoo项目实战之减少IO读写的导入思路

一个系统不管是大还是小,都是缺少不了导入导出的,一个系统如果拥有导入功能,能够带了很大的方便.因为itoo系统的各个系统都需要导入功能.由于我之前一直对导入有一定的研究,这个公共功能就落到的头上了.我主要是给大家介绍下我导入的整个思路以及后来的优化方案. 导入的整体思路可以用一下这张图来解释: 第一步是需要把填充好数据的excel转换为list集合. 第二步是把List集合批量保存到数据库相对应的表中. 以上是如何把填充好的excel导入到数据库中相对应的表的过程. 上面这张图主要介绍的是如果把

【java】itoo项目实战之百万数据查询优化收集与实践

1.对查询进行优化,应考虑在where 及 order by 涉及的列上建立索引. 2.应尽量避免在where 子句中对字段进行 null值判断,如:        select id from t wherenum is null 可以在num上设置默认值0,确保表中num列没有null值,然后这样查询: select idfrom t where num=0 3.应尽量避免在where 子句中使用!=或<>操作符. 4.应尽量避免在where 子句中使用 or 来连接条件,如: selec

【java】itoo项目实战之常被忽视的性能优化

Itoo V3.0很快就要结束了,功能上基本上开发完成了,但是放到jboss中部署的时候,使用时感觉特别的慢,如果是数据量多的话,就把慢这个词发挥到了极致.这个慢的问题有大部分是因为基础系统中使用了JPA级联导致的,每次查询的时候,只要有关联的表,都会全部查询出来,一下发出一大版的HQL 语句,看着也是挺吓人的.出来优化JPA级联问题,还可以从代码中下手,从以下的几个方面考虑. (1)减少对象生命周期 对象的生命周期有这么一个计算公式:对象生命周期=销毁时间-创建时间 实际上减少对象生命周期有2