码迷,mamicode.com
首页 > Web开发 > 详细

Hibernate批量处理海量数据的方法

时间:2016-11-22 01:50:34      阅读:285      评论:0      收藏:0      [点我收藏+]

标签:常见   cst   mit   压力   ssi   customers   插入数据   custom   blog   

本文实例讲述了Hibernate批量处理海量数据的方法。分享给大家供大家参考,具体如下:

Hibernate批量处理海量其实从性能上考虑,它是很不可取的,浪费了很大的内存。从它的机制上讲,Hibernate它是先把符合条件的数据查出来,放到内存当中,然后再进行操作。实际使用下来性能非常不理想,在笔者的实际使用中采用下面的第三种优化方案的数据是:100000条数据插入数据库, 需要约30分钟,呵呵,晕倒。(本人10分钟插入1000000条数据(字段比较小))

总结下来有三种来处理以解决性能问题:

  1:绕过Hibernate API ,直接通过 JDBC API 来做,这个方法性能上是比较好的。也是最快的。

  2:运用存储过程。

  3:还是用Hibernate API 来进行常规的批量处理,可以也有变,变就变在,我们可以在查找出一定的量的时候,及时的将这些数据做完操作就 删掉,session.flush();session.evict(XX对象集); 这样也可以挽救一点性能损失。这个"一定的量"要就要根据实际情况做定量参考了。一般为30-60左右,但效果仍然不理想。

  1:绕过Hibernate API ,直接通过 JDBC API 来做,这个方法性能上是比较好的,也是最快的。(实例为 更新操作)

1 Transaction tx=session.beginTransaction(); //注意用的是hibernate事务处理边界
2 Connection conn=session.connection();
3 PreparedStatement stmt=conn.preparedStatement("update CUSTOMER as C set C.sarlary=c.sarlary+1 where c.sarlary>1000");
4 stmt.excuteUpdate();
5 tx.commit(); //注意用的是hibernate事务处理边界

  这小程序中,采用的是直接调用JDBC 的API 来访问数据库,效率很高。避免了Hibernate 先查询出来加载到内存,再进行操作引发的性能问题

  2:运用存储过程。但这种方式考虑到易植和程序部署的方便性,不建议使用。(实例为 更新操作)

如果底层数据库(如Oracle)支持存储过程,也可以通过存储过程来执行批量更新。存储过程直接在数据库中运行,速度更加快。在Oracle数据库中可以定义一个名为batchUpdateCustomer()的存储过程,代码如下:

1 create or replace procedure batchUpdateCustomer(p_age in number) as begin update CUSTOMERS set AGE=AGE+1 where AGE>p_age;end;

  以上存储过程有一个参数p_age,代表客户的年龄,应用程序可按照以下方式调用存储过程:

1 tx = session.beginTransaction();
2 Connection con=session.connection();
3 String procedure = "{call batchUpdateCustomer(?) }";
4 CallableStatement cstmt = con.prepareCall(procedure);
5 cstmt.setInt(10); //把年龄参数设为0
6 cstmt.executeUpdate();
7 tx.commit();

  从上面程序看出,应用程序也必须绕过Hibernate API,直接通过JDBC API来调用存储过程。

  3:还是用Hibernate API 来进行常规的批量处理,可以也有变,变就变在,我们可以在查找出一定的量的时候,及时的将这些数据做完操作就删掉,session.flush();session.evict(XX对象集); 这样也可以挽救一点性能损失。这个"一定的量"要就要根据实际情况做定量参考了……
  (实例为 保存操作)

  业务逻辑为:我们要想数据库插入10 0000 条数据

 1 tx=session.beginTransaction();
 2 for(int i=0;i<100000;i++)
 3 {
 4 Customer custom=new Customer();
 5 custom.setName("user"+i);
 6 session.save(custom);
 7 if(i%50==0) // 以每50个数据作为一个处理单元,也就是我上面说的"一定的量",这个量是要酌情考虑的
 8 {
 9 session.flush();
10 session.clear();
11 }
12 }

  这样可以把系统维持在一个稳定的范围……

  在项目的开发过程之中,由于项目需求,我们常常需要把大批量的数据插入到数据库。数量级有万级、十万级、百万级、甚至千万级别的。如此数量级别的数据用Hibernate做插入操作,就可能会发生异常,常见的异常是OutOfMemoryError(内存溢出异常)。

  首先,我们简单来回顾一下Hibernate插入操作的机制。Hibernate要对它内部缓存进行维护,当我们执行插入操作时,就会把要操作的对象全部放到自身的内部缓存来进行管理。

谈到Hibernate的缓存,Hibernate有内部缓存与二级缓存之说。由于Hibernate对这两种缓存有着不同的管理机制,对于二级缓存,我们可以对它的大小进行相关配置,而对于内部缓存,Hibernate就采取了"放任自流"的态度了,对它的容量并没有限制。现在症结找到了,我们做海量数据插入的时候,生成这么多的对象就会被纳入内部缓存(内部缓存是在内存中做缓存的),这样你的系统内存就会一点一点的被蚕食,如果最后系统被挤"炸"了,也就在情理之中了。

  我们想想如何较好的处理这个问题呢?有的开发条件又必须使用Hibernate来处理,当然有的项目比较灵活,可以去寻求其他的方法。

  笔者在这里推荐两种方法:

  (1):优化Hibernate,程序上采用分段插入及时清除缓存的方法。
  (2):绕过Hibernate API ,直接通过 JDBC API 来做批量插入,这个方法性能上是最 好的,也是最快的。

  对于上述中的方法1,其基本是思路为:优化Hibernate,在配置文件中设置hibernate.jdbc.batch_size参数,来指定每次提交SQL的数量;程序上采用分段插入及时清除缓存的方法(Session实现了异步write-behind,它允许Hibernate显式地写操作的批处理),也就是每插入一定量的数据后及时的把它们从内部缓存中清除掉,释放占用的内存。

  设置hibernate.jdbc.batch_size参数,可参考如下配置。

1 <hibernate-configuration> <session-factory>……
2 <property name=" hibernate.jdbc.batch_size">50</property>……
3 <session-factory> <hibernate-configuration>

  配置hibernate.jdbc.batch_size参数的原因就是尽量少读数据库,hibernate.jdbc.batch_size参数值越大,读数据库的次数越少,速度越快。从上面的配置可以看出,Hibernate是等到程序积累到了50个SQL之后再批量提交。

  笔者也在想,hibernate.jdbc.batch_size参数值也可能不是设置得越大越好,从性能角度上讲还有待商榷。这要考虑实际情况,酌情设置,一般情形设置30、50就可以满足需求了。

  程序实现方面,笔者以插入10000条数据为例子,如

 1 Transatcion tx=session.beginTransaction();
 2 for(int i=0;i<10000;i++)
 3 {
 4 Student st=new Student();
 5 st.setName("feifei");
 6 session.save(st);
 7 if(i%50==0) //以每50个数据作为一个处理单元
 8 {
 9 session.flush(); //保持与数据库数据的同步
10 session.clear(); //清除内部缓存的全部数据,及时释放出占用的内存
11 }
12 }
13 tx.commit();
14 ……

  在一定的数据规模下,这种做法可以把系统内存资源维持在一个相对稳定的范围。

  注意:前面提到二级缓存,笔者在这里有必要再提一下。如果启用了二级缓存,从机制上讲Hibernate为了维护二级缓存,我们在做插入、更新、删除操作时,Hibernate都会往二级缓存充入相应的数据。性能上就会有很大损失,所以笔者建议在批处理情况下禁用二级缓存。

  对于方法2,采用传统的JDBC的批处理,使用JDBC API来处理。

  些方法请参照java 批处理自执行SQL

  看看上面的代码,是不是总觉得有不妥的地方?对,没发现么!这还是JDBC的传统编程,没有一点Hibernate味道。

  可以对以上的代码修改成下面这样:

 1 Transaction tx=session.beginTransaction(); //使用Hibernate事务处理
 2 Connection conn=session.connection();
 3 PrepareStatement stmt=conn.prepareStatement("insert into T_STUDENT(name) values(?)");
 4 for(int j=0;j++;j<200){
 5 for(int i=0;i++;j<50)
 6 {
 7 stmt.setString(1,"feifei");
 8 }
 9 }
10 stmt.executeUpdate();
11 tx.commit(); //使用 Hibernate事务处理边界
12 ……

  这样改动就很有Hibernate的味道了。笔者经过测试,采用JDBC API来做批量处理,性能上比使用Hibernate API要高将近10倍,性能上JDBC 占优这是无疑的。

  批量更新与删除Hibernate2中,对于批量更新操作,Hibernate是将符合要求的数据查出来,然后再做更新操作。批量删除也是这样,先把符合条件的数据查出来,然后再做删除操作。

  这样有两个大缺点:

  (1):占用大量的内存。
  (2):处理海量数据的时候,执行update/delete语句就是海量了,而且一条update/delete语句只能操作一个对象,这样频繁的操作数据库,性能低下应该是可想而知的了。

  Hibernate3 发布后,对批量更新/删除操作引入了bulk update/delete,其原理就是通过一条HQL语句完成批量更新/删除操作,很类似JDBC的批量更新/删除操作。在性能上,比Hibernate2的批量更新/删除有很大的提升。

1 Transaction tx=session.beginSession();
2 String HQL="delete STUDENT";
3 Query query=session.createQuery(HQL);
4 int size=query.executeUpdate();
5 tx.commit();
6 ……

  控制台输出了也就一条删除语句Hibernate:delete from T_STUDENT,语句执行少了,性能上也与使用JDBC相差无几,是一个提升性能很好的方法。当然为了有更好的性能,笔者建议批量更新与删除操作还是使用JDBC,方法以及基本的知识点与上面的批量插入方法2基本相同,这里就不在冗述。

  笔者这里再提供一个方法,就是从数据库端来考虑提升性能,在Hibernate程序端调用存储过程。存储过程在数据库端运行,速度更快。以批量更新为例,给出参考代码。

  首先在数据库端建立名为batchUpdateStudent存储过程:

1 create or replace produre batchUpdateStudent(a in number) as
2 begin
3 update STUDENT set AGE=AGE+1 where AGE>a;
4 end;
1 Transaction tx=session.beginSession();
2 Connection conn=session.connection();
3 String pd="……{call batchUpdateStudent(?)}";
4 CallableStatement cstmt=conn.PrepareCall(pd);
5 cstmt.setInt(120); //把年龄这个参数设为20
6 tx.commit();

  观察上面的代码,也是绕过Hibernate API,使用 JDBC API来调用存储过程,使用的还是Hibernate的事务边界。存储过程无疑是提高批量处理性能的一个好方法,直接运行与数据库端,某种程度上讲把批处理的压力转接给了数据库。

  参考博客:http://www.jb51.net/article/81436.htm

Hibernate批量处理海量数据的方法

标签:常见   cst   mit   压力   ssi   customers   插入数据   custom   blog   

原文地址:http://www.cnblogs.com/lcngu/p/6071363.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!