HIBERNATE性能优化
(初稿)
一、 前言
数据库的出现解放了我们的数据跟踪能力,然而长期以来,关系数据库的操作是基于行集的,对关系数据库的操纵接口也是基于行集的,应用程序中承担着从行集中提取数据的繁重工作。
然而,ORM(实体关系映射)的出现使得关系数据库中表的数据映射成为对象,以对象的形式展现,这样开发人员就可以把对数据库的操作转化为对这些对象的操作,实现了以面向对象的方法来操纵数据库。
能实现ORM这个功能的框架有很多,Hibernate可以说是这些框架中最流行、最受开发者关注的,甚至连JBoss公司也把它吸收进来,利用它在自己的项目中实现ORM功能。
然而,hibernate在数据库的操纵上也存在着问题,针对此问题须采用合适的方案来加以解决,否则将造成应用程序的性能瓶颈。
二、 性能优化
实现同一功能,用HIBERNATE与用JDBC性能相差十几倍很正常,如果不及
早调整,很可能影响整个项目的进度。
对hibernate的性能主要考虑以下几点:
1、 hibernate版本选用
hibernate3.x提供了一些有助于性能提升的特性,如经过优化的批量处理机制、代理机制、属性的延迟加载支持等。
2、 数据库设计
a) 降低关联的复杂性
b) 尽量不使用联合主键
c) ID的生成机制,不同的数据库所提供的机制并不完全一样
d) 适当的冗余数据,不过分追求高范式
3、 制定合理的缓存策略
缓存对于整体性能有着关键的提升,制定合理的缓存是提高性能的一个
有效途径,减少与数据库的交互。
4、 合理的session管理机制
在利用Hibernate开发DAO模块时,我们和Session打的交道最多,所以
如何合理的管理Session,避免Session的频繁创建和销毁,对于提高系统的性能来说是非常重要的。
5、 尽量使用延迟加载特性
对于无需立即加载的数据,应通过延迟加载特性应需加载,以避免系统资
源的无谓消耗。
6、 事务控制
事务方面对性能有影响的主要包括:事务方式的选用,事务隔离级别以及锁
的选用
a) 事务方式选用:如果不涉及多个事务管理器事务的话,不需要使用JTA,只有JDBC的事务控制就可以。
b) 事务隔离级别:参见标准的SQL事务隔离级别
c) 锁的选用:悲观锁(一般由具体的事务管理器实现),对于长事务效率低,但安全。乐观锁(一般在应用级别实现),如在HIBERNATE中可以定义 VERSION字段,显然,如果有多个应用操作数据,且这些应用不是用同一种乐观锁机制,则乐观锁会失效。因此,针对不同的数据应有不同的策略,同前面许多情况一样,很多时候我们是在效率与安全/准确性上找一个平衡点,无论如何,优化都不是一个纯技术的问题,你应该对你的应用和业务特征有足够的了解。
7、 使用合适的连接池
三、 优化策略
1. 使用缓存
对于ORM实现而言,缓存的使用是持久层性能提升的关键。相对JDBC数据存取,ORM实现往往需要借助更加复杂的机制,以实现内部状态的管理、OR关系的映射等。
缓存是数据库数据在内存中的临时容器,它包含了库表数据在内存中的临时拷贝,位于数据库与数据访问层之间:
ORM在进行数据读取时,会根据基缓存管理策略,首先在缓存中查询,如果在缓存中命中,则直接以此数据作业查询结果加以利用,从而避免了数据库调用的性能开销。往往从内存中读取数据比从数据库中读取要快得多。
ORM的数据缓存主要包括:事物级缓存、应用级缓存、分布式缓存。
1) 事务级缓存
当前事务范围内的数据级存策略,可以是一个数据库事务,也可以是某个应用级事务,对hibernate而言,事务级缓存是基于session生命周期实现的,每个session会在内部给持一个数据级存,此缓存随着session的创建而存在,销毁而消亡。
2) 应用级缓存
此缓存可由多个事务共享。在hibernate中,应用级缓存在
sessionfactory中实现,所以由sessionfactory所创建的session实例共享此缓存。
3) 分布式缓存
在多个应用实例、多个JVM之间共享缓存。
由多个应用级缓存实例组成集群,通过某种远程机制,如:RMI或JMS,实现各个缓存实例间的数据同步,任何一个实例的数据修改将导致整个集群间的数据状态同步。
Hibernate缓存分为二级,第一级存放于session中称为一级缓存,默认带有且不能卸载。
第二级是由sessionFactory控制的进程级缓存。是全局共享的缓存,凡是会调用二级缓存的查询方法 都会从中受益。只有经正确的配置后二级缓存才会发挥作用。同时在进行条件查询时必须使用相应的方法才能从缓存中获取数据。比如Query.iterate()方法、load、get方法等。必须注意的是session.find方法永远是从数据库中获取数据,不会从二级缓存中获取数据,即便其中有其所需要的数据也是如此。
查询时使用缓存的实现过程为:首先查询一级缓存中是否具有需要的数据,如果没有,查询二级缓存,如果二级缓存中也没有,此时再执行查询数据库的工作。要注意的是:此3种方式的查询速度是依次降低的。
1) 一级缓存
Query中:get() 、load() 、iterate均使用一级缓存。
因为Session的生命期往往很短,存在于Session内部的第一级最快缓存的生命期当然也很短,所以第一级缓存的命中率是很低的。其对系统性能的改善也是很有限的。当然,这个Session内部缓存的主要作用是保持Session内部数据状态同步。
2) 二级缓存
hibernate会自行维护二级缓存中的数据,以保证缓存中的数据和数据库中的真实数据的一致性!无论何时,当你调用save()、update()或 saveOrUpdate()方法传递一个对象时,或使用load()、 get()、list()、iterate() 或scroll()方法获得一个对象时, 该对象都将被加入到Session的内部缓存中。 当随后flush()方法被调用时,对象的状态会和数据库取得同步。
也就是说删除、更新、增加数据的时候,同时更新缓存。当然这也包括二级缓存!
只要是调用hibernate API执行数据库相关的工作。hibernate都会为你自动保证缓存数据的有效性!
3) 使用缓存时应注意的问题
并非所有的情况都适合于使用二级缓存,需要根据具体情况来决定。同时可以针对某一个持久化对象配置其具体的缓存策略,并且须符合以下条件:
数据不会被第三方修改:
一般情况下,会被hibernate以外修改的数据最好不要配置二级缓存,以免引起不一致的数据。但是如果此数据因为性能的原因需要被缓存,同时又有可能被第3方比如SQL修改,如果你使用了JDBC绕过hibernate直接执行对数据库的操作。此时,Hibernate不会/也不可能自行感知到数据库被进行的变化改动,也就不能再保证缓存中数据的有效性!只是此时需要在sql执行修改后手动调用cache的清除方法。以保证数据的一致性
虽然hibernate提供了cache手动调用的方法,但是维护起来极其不方便,为此在使用缓存时尽量避免数据被第三方修改,统一由hibernate进行维护。
数据大小在可接收范围之内:
如果数据表数据量特别巨大,此时不适合于二级缓存。原因是缓存的数据量过大可能会引起内存资源紧张,反而降低性能。
如果数据表数据量特别巨大,但是经常使用的往往只是较新的那部分数据。此时,也可为其配置二级缓存。但是必须单独配置其持久化类的缓存策略,比如最大缓存数、缓存过期时间等,将这些参数降低至一个合理的范围(太高会引起内存资源紧张,太低了缓存的意义不大)。
数据更新频率高:
对于数据更新频率过高的数据,频繁同步缓存中数据的代价可能和 查询缓存中的数据从中获得的好处相当,坏处益处相抵消。此时缓存的意义也不大。
关键数据:
财务数据等是非常重要的数据,绝对不允许出现或使用无效的数据,所以此时为了安全起见最好不要使用二级缓存。
N+1问题:
执行条件查询时,iterate()方法具有著名的 “n+1”次查询的问题,也就是说在第一次查询时iterate方法查询的方式是:将满足条件的记录ID查询出来,然后在进行迭代查询时再用查询结果集中的ID去逐个查询。查询的效次数就是(n+1)次,查询的结果被保留在缓存当中,下一次查询时将从缓存中取,该问题须特别注意,最好的情况下,n+1全部命中,最坏的情况下则将查询n+1次数据库。
4) 缓存机制的实现与配置
Hibernate本身并未提供二级缓存的产品化实现(只是提供了一个基于Hashtable的简单缓存以供调试),而是为众多的第三方缓存组件提供了接入接口,可以根据实际情况选择不同的缓存实现。
较常用的第三方组件有:
1. JCS
2. EHCache
3. OSCache
4. JBossCache
5. SwarmCache
Hibernate中启用二级缓存,需要在hibernate.cfg.xml配置hibernate.cache.provider_class参数,之后,需要在映射文件中指定各个映射实体(以及collection)的缓存同步策略。Hibernate提供了一下4种内置的缓存同步策略:
1. read-only
只读。对于不会发生改变的数据,可使用只读型缓存。
2. nonstrict-read-write
如果程序对并发访问下的数据同步要求不是非常严格,且数据更新操作频率较低,可以采用本选项,获得较好的性能。
3. read-write
严格可读写缓存。基于时间戳判定机制,实现了“read committed”事务隔离等级。可用于对数据同步要求严格的情况,但不支持分布式缓存。这也是实际应用中使用最多的同步策略。
4. transactional
事务型缓存,必须运行在JTA事务环境中。
2. 使用EHCache
EHCache是一种常用的轻量级二级缓存工具,hibernate对其提供了接入接口,能较好地进行结合。具体的配置请参见ehcache配置文档。
3. session管理
在利用Hibernate开发DAO模块时,我们和Session打的交道最多,所以如何合理的管理Session,避免Session的频繁创建和销毁,对于提高系统的性能来说是非常重要的。
Session是由SessionFactory负责创建的,而SessionFactory的实现是线程安全的,多个并发的线程可以同时访问一个SessionFactory并从中获取Session实例,然而Session却并非线程安全的。Session中包含了数据库操作相关的状态信息,那么说如果多个线程同时使用一个Session实例进行CRUD,就很有可能导致数据存取的混乱。
幸运的是,Spring框架为Hibernate延迟加载与DAO模式的整合提供了一种方便的解决方法。以一个Web应用为例,Spring提供了OpenSessionInViewFilter和OpenSessionInViewInterceptor。我们可以随意选择一个类来实现相同的功能。两种方法唯一的不同就在于interceptor在Spring容器中运行并被配置在web应用的上下文中,而Filter在Spring之前运行并被配置在web.xml中。不管用哪个,他们都在请求将当前会话与当前(数据库)线程绑定时打开Hibernate会话。一旦已绑定到线程,这个打开了的Hibernate会话可以在DAO实现类中透明地使用。这个会话会为延迟加载数据库中值对象的视图保持打开状态。一旦这个逻辑视图完成了,Hibernate会话会在Filter的doFilter方法或者Interceptor的postHandle方法中被关闭。
实现方法在web.xml中加入:
<filter>
<filter-name>hibernateFilter</filter-name>
<filter-class>
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter
</filter-class>
</filter
<filter-mapping>
<filter-name>hibernateFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
四、 CDMS系统优化建议
CDMS2.0中也存在着相当多的性能问题与瓶颈,数据库的操纵都是使用hibernate进行操纵和管理,然而对于一个业务逻辑的流程,却容易导致多次操作数据库,以及在终端数目较多的情况下频繁创建和销毁session对象,这样造成的系统开销极大,虽然使用了连接池,但是性能上还是存在缺陷。
解决cdms2.0性能上的问题主要集中在缓存的使用和对session的管理,此前曾做过简单的测试,查询1000台终端,在使用缓存的情况下效率是不使用缓存的3~5倍,因此解决以上两个问题至关重要。