有很多人认为Hibernate天生效率比较低,确实,在普遍情况下,需要将执行转换为SQL语句的 Hibernate的效率低于直接JDBC存取,然而,在经过比较好的性能优化之后,Hibernate的性能还是让人相当满意的,特别是应用二级缓存之 后,甚至可以获得比较不使用缓存的JDBC更好的性能,下面介绍一些通常的Hibernate的优化策略:
1.抓取 优化
抓取是指Hibernate如何在关联关系之间进行导航的时候,Hibernate如何获取 关联对象的策略,其主要定义了两个方面:如何抓取和何时抓取
1)如何抓取。
Hibernate3主要有两种种抓取方式,分别应用于对象关联实例(many-to-one、one-to-one)和对象关联集合(set、map等),总共是四种变种
JOIN抓取: 通过在SELECT语句中使用OUTER JOIN来获得对象的关联实例或者关联集合)
SELECT抓取: 另外发送一条SELECT语句来抓取当前对象的关联实体和集合
在我的开发经历中,此处对性能的优化是比较有限的,并不值得过多关注
例:
A.应用于对象关联实例(默认是false)
<many-to-one name=".." outer-join="true/false/auto" .../>
B.应用于对象关联集合(默认是auto)
<set name=".." fetch="join/select" ... >
....
</set>
2)何时抓取
主要分为延迟加载和立即抓取,默认的情况下Hibernate3对对象关联实采用延迟加载,普通属性采用立即抓取,通过延迟加载和采用适当的抓取粒度,与不采用优化相比往往可以将性能提升数倍
立即抓取:当抓取宿主对象时,同时抓取其关联对象和关联集以及属性
延迟加载:当抓取宿主对象时,并不抓取其关联对象,而是当对其对象进行调用时才加载
例:
A.应用于对象关联实例(默认是延迟加载)
<many-to-one name=".." lazy="true/false" .../>
B.应用于对象关联集合(默认是延迟加载)
<set name=".." lazy="true/false" ... >
....
</set>
对于延迟加载,需要注意的时,对延迟对象的使用必须在Session关闭之前进行,Hibernate的 LazyInitalizationException往往就是由于在Session的生命期外使用了延迟加载的对象。当我们进行Web开发时,可以使用 OpenSessionInView模式,当请求开始时打开session,当请求响应结束时才关闭session,不过,在使用 OpenSessionInView模式时,需要注意如果响应时间比较长(业务比较复杂或者客户端是低速网络),将Session资源(也就是数据库的连 接)占用太久的话可以会导致资源耗尽
3)抓取粒度
抓取粒度指的是对象在关联关系之间被导航时一次预先加载的数量,Hibernate程序的性能比较差往往就在于没有对抓取粒度仔细考虑,当加载一个列表并在列表中的每个对象中对其关联进行导航时,往往导致N+1条SQL语句查询。
例:
A.应用于对象关联实例(默认为1),注意,对对象关联实例的设 置是在被关联的对象之上的,譬如
class User
{
Group g;
}
那么抓取粒度应该在Group的配置文件之上,见下
<class name="Group" table="group" batch-size="..">
...
</class>
对该值并没有一个约定俗成的值,根据情况而定,如果被关联表数据比较少,则可以设置地小一些,3-20,如果比较大则可以设到30-50,注意的时候,并不是越多越好,当其值超过50之后,对性能并没有多大改善但却无谓地消耗内存
假设有如下例子:
List<User> users = query.list();
如果有20个User,并对这20个User及其Group进行遍历,如果不设置batch-size(即batch-size="1"),则在最糟糕的情况
下,需要1 + 20条SQL语句,如果设置batch-size="10",则最好的情况下只需要1 + 2条SQL语句
B.应用于对象关联集合(默认为1)
<set name=".." batch-size="" ... >
....
</set>
2.二级缓存
Hibernate 对数据的缓存包括两个级:一级缓存,在Session的级别上进行,主要是对象缓存,以其id为键保存对象,在Session的生命期间存在;二级缓存, 在SessionFactory的级别上进行,有对象缓存和查询缓存,查询缓存以查询条件为键保存查询结果,在SessionFactory的生命期间存 在。默认地,Hibernate只启用一级缓存,通过正确地使用二级缓存,往往可以获得意想不到的性能。
1)对象缓存:
当抓取一个对象之后,Hiberate将其以id为键缓存起来,当下次碰到抓取id相同的对象时,可以使用如下配置
方法1:在缓存对象上配置
<class ...>
<cache useage="read-only/write/...." regions="group" />
</class>
useage 表示使用什么类型的缓存,譬如只读缓存、读写缓存等等(具体参见Hibernate参考指南),值得注意的时,有部分缓存在Hibernate的实现中不 支持读写缓存,譬如JBossCache在Hibernate的实现中只是一种只读缓存,具体缓存实现对缓存类型的支持情况,可以参见 org.hibernate .cache包
regions表示缓存分块,大部分的缓存实现往往对缓存进行分块,该部分是可选的,详细参见各缓存实现
方法2:在hibernate.cfg.xml中配置
<cache class=".." useage=".." regions=".."/>
我认为第二种更好,可以统一管理
2)查询缓存
查询时候将查询结果以查询条件为键保存起来,需要配置如下
A.在hibernate.cfg.xml中配置(启用查询缓存)
<property name="hibernate.cache.use_query_cache">true</property> (前面的属性名可参见常量
org.hibernate.cfg.Enviroment.USE_QUERY_CACHE)
B.程序
query.setCacheable(true);
query.setCacheRegions(...);
需要注意的是,查询缓存与对象缓存要结合更有效,因为查询缓存仅缓存查询结果列表的主键数据
一般情况下在开发中,对一些比较稳定而又被频繁引用的数据,譬如数据字典之类的,将其进行二级缓存,对一些查询条件和查询数据变化不频繁而又常常被 使用的查询,将其进行二级缓存。由于二级缓存是放在内存中,而且Hibernate的缓存不是弱引用缓存(WeekReference),所以注意不要将 大块的数据放入其中,否则可能会被内存造成比较大的压力。
3.批量数据操作
当进行大批量数据操作(几万甚至几十几百万)时,需要注意两点,一,批量提交,二,及时清除不需要的一级缓存数据
1)所谓的批量提交,就是不要频繁使用session的flush,每一次进行flush,Hibernate将PO数据于数据库进行同步,对于海 量级数据操作来说是性能灾难(同时提交几千条数据和提交一条数据flush一次性能差别可能会是几十倍的差异)。一般将数据操作放在事务中,当事务提交时 Hibernate自动帮你进行flush操作。
2)及时清除不需要的一级缓存数据:由于Hibernate默认采用一级缓存,而在 session的生命期间,所有数据抓取之后会放入一级缓存中,而当数据规模比较庞大时,抓取到内存中的数据会让内存压力非常大,一般分批操作数据,被一 次操作之后将一级缓存清除,譬如
session.clear(User.class)
4.杂项
dynamic-insert,dynamic-update,动态插入和动态更新,指的是让Hibernate插入数据时仅插入非空数据,当修改数据时只修改变化的数据,譬如对于
class User
{
id
username
password
}
如果u.id=1, u.username="ayufox",u.password=null,那么如果不设置动态插入,则其sql语句是 insert into users(id, username, password) values (1, 'ayufox', '),如果设置则其 sql语句是insert into users(username) valeus('ayufox')
在如上的情况下,如果修改 u.password='11',那么如果不设置动态更新,则sql语句为update users set username='ayufox', password='11' where id = 1,如果设置则为update user set password='11' where d = 1
设置是在class的映射文件中,如下
<class name="User" table="users" dynamic-insert="true/false" dynamic-update="true/false" ...>
</class>
该设置对性能的提升比较有限
本文依照HIBERNATE帮助文档,一些网络书籍及项目经验整理而成,只提供要点和思路,具体做法可以留言探讨,或是找一些更详细更有针对性的资料。
初用HIBERNATE的人也许都遇到过性能问题,实现同一功能,用HIBERNATE与用JDBC性能相差十几倍很正常,如果不及早调整,很可能影响整个项目的进度。
大体上,对于HIBERNATE性能调优的主要考虑点如下:
? 数据库设计调整
? HQL优化
? API的正确使用(如根据不同的业务类型选用不同的集合及查询API)
? 主配置参数(日志,查询缓存,fetch_size, batch_size等)
? 映射文件优化(ID生成策略,二级缓存,延迟加载,关联优化)
? 一级缓存的管理
? 针对二级缓存,还有许多特有的策略
? 事务控制策略。
1、 数据库设计
a) 降低关联的复杂性
b) 尽量不使用联合主键
c) ID的生成机制,不同的数据库所提供的机制并不完全一样
d) 适当的冗余数据,不过分追求高范式
2、 HQL优化
HQL如果抛开它同HIBERNATE本身一些缓存机制的关联,HQL的优化技巧同普通的SQL优化技巧一样,可以很容易在网上找到一些经验之谈。
3、 主配置
a) 查询缓存,同下面讲的缓存不太一样,它是针对HQL语句的缓存,即完全一样的语句再次执行时可以利用缓存数据。但是,查询缓存在一个交易系统(数据变更频繁,查询条件相同的机率并不大)中可能会起反作用:它会白白耗费大量的系统资源但却难以派上用场。
b) fetch_size,同JDBC的相关参数作用类似,参数并不是越大越好,而应根据业务特征去设置
c) batch_size同上。
d) 生产系统中,切记要关掉SQL语句打印。
4、 缓存
a) 数据库级缓存:这级缓存是最高效和安全的,但不同的数据库可管理的层次并不一样,比如,在ORACLE中,可以在建表时指定将整个表置于缓存当中。
b) SESSION 缓 存:在一个HIBERNATE SESSION有效,这级缓存的可干预性不强,大多于HIBERNATE自动管理,但它提供清除缓存的方法,这在大批量增加/更新操作是有效的。比如,同 时增加十万条记录,按常规方式进行,很可能会发现OutofMemeroy的异常,这时可能需要手动清除这一级缓存:Session.evict以及 Session.clear
c) 应用缓存:在一个SESSIONFACTORY中有效,因此也是优化的重中之重,因此,各类策略也考虑的较多,在将数据放入这一级缓存之前,需要考虑一些前提条件:
i. 数据不会被第三方修改(比如,是否有另一个应用也在修改这些数据?)
ii. 数据不会太大
iii. 数据不会频繁更新(否则使用CACHE可能适得其反)
iv. 数据会被频繁查询
v. 数据不是关键数据(如涉及钱,安全等方面的问题)。
缓存有几种形式,可以在映射文件中配置:read-only(只读,适用于很少变更的静态数据/历史数据),nonstrict-read- write,read-write(比较普遍的形式,效率一般),transactional(JTA中,且支持的缓存产品较少)
d) 分布式缓存:同c)的配置一样,只是缓存产品的选用不同,在目前的HIBERNATE中可供选择的不多,oscache, jboss cache,目前的大多数项目,对它们的用于集群的使用(特别是关键交易系统)都持保守态度。在集群环境中,只利用数据库级的缓存是最安全的。
5、 延迟加载
a) 实体延迟加载:通过使用动态代理实现
b) 集合延迟加载:通过实现自有的SET/LIST,HIBERNATE提供了这方面的支持
c) 属性延迟加载:
6、 方法选用
a) 完成同样一件事,HIBERNATE提供了可供选择的一些方式,但具体使用什么方式,可能用性能/代码都会有影响。显示,一次返回十万条记录(List /Set/Bag/Map等)进行处理,很可能导致内存不够的问题,而如果用基于游标(ScrollableResults)或Iterator的结果 集,则不存在这样的问题。
b) Session的load/get方法,前者会使用二级缓存,而后者则不使用。
c) Query和list/iterator,如果去仔细研究一下它们,你可能会发现很多有意思的情况,二者主要区别(如果使用了Spring,在HibernateTemplate中对应find,iterator方法):
i. list只能利用查询缓存(但在交易系统中查询缓存作用不大),无法利用二级缓存中的单个实体,但list查出的对象会写入二级缓存,但它一般只生成较少的执行SQL语句,很多情况就是一条(无关联)。
ii. iterator则可以利用二级缓存,对于一条查询语句,它会先从数据库中找出所有符合条件的记录的ID,再通过ID去缓存找,对于缓存中没有的记录,再 构造语句从数据库中查出,因此很容易知道,如果缓存中没有任何符合条件的记录,使用iterator会产生N+1条SQL语句(N为符合条件的记录数)
iii. 通过iterator,配合缓存管理API,在海量数据查询中可以很好的解决内存问题,如:
while(it.hasNext()){
YouObject object = (YouObject)it.next();
session.evict(youObject);
sessionFactory.evice(YouObject.class, youObject.getId());
}
如果用list方法,很可能就出OutofMemory错误了。
iv. 通过上面的说明,我想你应该知道如何去使用这两个方法了。
7、 集合的选用
在HIBERNATE 3.1文档的“19.5. Understanding Collection performance”中有详细的说明。
8、 事务控制
事务方面对性能有影响的主要包括:事务方式的选用,事务隔离级别以及锁的选用
a) 事务方式选用:如果不涉及多个事务管理器事务的话,不需要使用JTA,只有JDBC的事务控制就可以。
b) 事务隔离级别:参见标准的SQL事务隔离级别
c) 锁的选用:悲观锁(一般由具体的事务管理器实现),对于长事务效率低,但安全。乐观锁(一般在应用级别实现),如在HIBERNATE中可以定义 VERSION字段,显然,如果有多个应用操作数据,且这些应用不是用同一种乐观锁机制,则乐观锁会失效。因此,针对不同的数据应有不同的策略,同前面许 多情况一样,很多时候我们是在效率与安全/准确性上找一个平衡点,无论如何,优化都不是一个纯技术 的问题,你应该对你的应用和业务特征有足够的了解。
9、 批量操作
即使是使用JDBC,在进行大批数据更新时,BAT CH与不使用BATCH有效率上也有很大的差别。我们可以通过设置batch_size来让其支持批量操作。
举个例子,要批量删除某表中的对象,如“delete Account”,打出来的语句,会发现HIBERNATE找出了所有ACCOUNT的ID,再进行删除,这主要是为了维护二级缓存,这样效率肯定高不 了,在后续的版本中增加了bulk delete/update,但这也无法解决缓存的维护问题。也就是说,由于有了二级缓存的维护问题,HIBERNATE的批量操作效率并不尽如人意!
从前面许多要点可以看出,很多时候我们是在效率与安全/准确性上找一个平衡点,无论如何,优化都不是一个纯技术的问题,你应该对你的应用和业务特征有足 够的了解,一般的,优化方案应在架构设计期就基本确定,否则可能导致没必要的返工,致使项目延期,而作为架构师和项目经理,还要面对开发人员可能的抱怨, 必竟,我们对用户需求更改的控制力不大,但技术/架构风险是应该在初期意识到并制定好相关的对策。
还有一点要注意,应用层的缓存只是锦上添花,永远不要把它当救命稻草,应用的根基(数据库设计,算法,高效的操作语句,恰当API的选择等)才是最重要的。
Hibernate的缓存***********************************
1、首先设置EhCache,建立配置文件ehcache.xml,默认的位置在class-path,可以放到你的src目录下:
Xml代码 复制代码
1. <?xml version="1.0" encoding="UTF-8"?>
2. <ehcache>
3. <diskStore path="java .io.tmpdir"/>
4. <defaultCache
5. maxElementsInMemory="10000" <!-- 缓存最大数目 -->
6. eternal="false" <!-- 缓存是否持久 -->
7. overflowToDisk="true" <!-- 是否保存到磁盘,当系统当机时-->
8. timeToIdleSeconds="300" <!-- 当缓存闲置n秒后销毁 -->
9. timeToLiveSeconds="180" <!-- 当缓存存活n秒后销毁-->
10. diskPersistent="false"
11. diskExpiryThreadIntervalSeconds= "120"/>
12. </ehcache>
<?xml version="1.0" encoding="UTF-8"?>
<ehcache>
<diskStore path="java.io.tmpdir"/>
<defaultCache
maxElementsInMemory="10000" <!-- 缓存最大数目 -->
eternal="false" <!-- 缓存是否持久 -->
overflowToDisk="true" <!-- 是否保存到磁盘,当系统当机时-->
timeToIdleSeconds="300" <!-- 当缓存闲置n秒后销毁 -->
timeToLiveSeconds="180" <!-- 当缓存存活n秒后销毁-->
diskPersistent="false"
diskExpiryThreadIntervalSeconds= "120"/>
</ehcache>
2、在Hibernate配置文件中设置:
Xml代码 复制代码
1. <!-- 设置Hibernate的缓存接口类,这个类在Hibernate包中 -->
2. <property name="cache.provider_class">org.hibernate.cache.EhCacheProvider</property>
3. <!-- 是否使用查询缓存 -->
4. <property name="hibernate.cache.use_query_cache">true</property>
5. 如果使用spring调用Hibernate的sessionFactory的话,这样设置:
6. <!--HibernateSession工厂管理 -->
7. <bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
8. <property name="dataSource">
9. <ref bean="datasource" />
10. </property>
11. <property name="hibernateProperties">
12. <props>
13. <prop key="hibernate.dialect">org.hibernate.dialect.Oracle9Dialect</prop>
14. <prop key="connection.provider_class">org.hibernate.connection.C3P0ConnectionProvider</prop>
15. <prop key="hibernate.show_sql">true</prop>
16. <prop key="hibernate.cache.use_query_cache">true</prop>
17. <prop key="hibernate.cache.provider_class">org.hibernate.cache.EhCacheProvider</prop>
18. </props>
19. </property>
20. <property name="mappingDirectoryLocations">
21. <list>
22. <value>/WEB-INF/classes/cn/rmic/manager/hibernate/</value>
23. </list>
24. </property>
25. </bean>
<!-- 设置Hibernate的缓存接口类,这个类在Hibernate包中 -->
<property name="cache.provider_class">org.hibernate.cache.EhCacheProvider</property>
<!-- 是否使用查询缓存 -->
<property name="hibernate.cache.use_query_cache">true</property>
如果使用spring调用Hibernate的sessionFactory的话,这样设置:
<!--HibernateSession工厂管理 -->
<bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
<property name="dataSource">
<ref bean="datasource" />
</property>
<property name="hibernateProperties">
<props>
<prop key="hibernate.dialect">org.hibernate.dialect.Oracle9Dialect</prop>
<prop key="connection.provider_class">org.hibernate.connection.C3P0ConnectionProvider</prop>
<prop key="hibernate.show_sql">true</prop>
<prop key="hibernate.cache.use_query_cache">true</prop>
<prop key="hibernate.cache.provider_class">org.hibernate.cache.EhCacheProvider</prop>
</props>
</property>
<property name="mappingDirectoryLocations">
<list>
<value>/WEB-INF/classes/cn/rmic/manager/hibernate/</value>
</list>
</property>
</bean>
说明一下:如果不设置“查询缓存”,那么hibernate只会缓存使用load()方法获得的单个持久化对象,如果想缓存使用 findall()、list()、Iterator()、createCriteria()、createQuery()等方法获得的数据结果集的话, 就需要设置
hibernate.cache.use_query_cache true 才行
3、在Hbm文件中添加<cache usage="read-only"/>
4、如果需要“查询缓存”,还需要在使用Query或Criteria()时设置其setCacheable(true);属性
5、实践出真知,给一段测试程序,如果成功的话第二次查询时不会读取数据库
Java代码 复制代码
1. package cn.rmic.hibernatesample;
2.
3. import java.util.List;
4.
5. import org.hibernate.CacheMode;
6. import org.hibernate.Criteria;
7. import org.hibernate.Query;
8. import org.hibernate.Session;
9.
10. import cn.rmic.hibernatesample.hibernate.HibernateSessionFactory;
11. import cn.rmic.manager.po.Resources;
12.
13. public class testCacheSelectList ...{
14.
15. /** *//**
16. * @param args
17. */
18. public static void main(String[] args) ...{
19. // TODO Auto-generated method stub
20.
21. Session s=HibernateSessionFactory.getSession();
22. Criteria c=s.createCriteria(Resources.class);
23. c.setCacheable(true);
24. List l=c.list();
25. // Query q=s.createQuery("From Resources r")
26. // .setCacheable(true)
27. // .setCacheRegion("frontpages") ;
28. // List l=q.list();
29. Resources resources=(Resources)l.get(0);
30. System.out.println("-1-"+resources.getName());
31. HibernateSessionFactory.closeSession();
32. try ...{
33. Thread.sleep(5000);
34. } catch (InterruptedException e) ...{
35. // TODO Auto-generated catch block
36. e.printStackTrace();
37. }
38. s=HibernateSessionFactory.getSession();
39. c=s.createCriteria(Resources.class);
40. c.setCacheable(true);
41. l=c.list();
42. // q=s.createQuery("From Resources r").setCacheable(true)
43. // .setCacheRegion("frontpages");
44. // l=q.list();
45. resources=(Resources)l.get(0);
46. System.out.println("-2-"+resources.getName());
47. HibernateSessionFactory.closeSession();
48. }
49. }
一。 inverse = ?
inverse=false(default)
用于单向one-to-many关联
parent.getChildren().add(child) // insert child
parent.getChildren().delete(child) // delete child
inverse=true
用于双向one-to-many关联
child.setParent(parent); session.save(child) // insert child
session.delete(child)
在分层结构的体系中
parentDao, childDao对于CRUD的封装导致往往直接通过session接口持久化对象,而很少通过关联对象可达性
二。 one-to-many关系
单向关系还是双向关系?
parent.getChildren().add(child)对集合的触及操作会导致lazy的集合初始化,在没有对集合配置二级缓存的情况下,应避免此类操作
select * from child where parent_id = xxx;
性能口诀:
1. 一般情况下避免使用单向关联,尽量使用双向关联
2. 使用双向关联,inverse=“true”
3. 在分层结构中通过DAO接口用session直接持久化对象,避免通过关联关系进行可达性持久化
三。many-to-one关系
单向many-to-one表达了外键存储方
灵活运用many-to-one可以避免一些不必要的性能问题
many-to-one表达的含义是:0..n : 1,many可以是0,可以是1,也可以是n,也就是说many-to-one可以表达一对多,一对一,多对一关系
因此可以配置双向many-to-one关系,例如:
1. 一桌四人打麻将,麻将席位和打麻将的人是什么关系?是双向many-to-one的关系
四。one-to-one
通过主键进行关联
相当于把大表拆分为多个小表
例如把大字段单独拆分出来,以提高数据库操作的性能
Hibernate的one-to-one似乎无法lazy,必须通过bytecode enhancement
五。集合List/Bag/Set
one-to-many
1. List需要维护index column,不能被用于双向关联,必须inverse=“false”,被谨慎的使用在某些稀有的场合
2. Bag/Set语义上没有区别
3. 我个人比较喜欢使用Bag
many-to-many
1. Bag和Set语义有区别
2。 建议使用Set
六。集合的过滤
1. children = session.createFilter(parent.getChildren(), “where this.age > 5 and this.age < 10”).list()
针对一对多关联当中的集合元素非常庞大的情况,特别适合于庞大集合的分页:
session.createFilter(parent.getChildren(),“”).setFirstResult(0).setMaxResults(10).list();
在hibernate 中用 super.getSession().createFilter( , )
七。继承关系当中的隐式多态
HQL: from Object
1. 把所有数据库表全部查询出来
2. polymorphism=“implicit”(default)将当前对象,和对象所有继承子类全部一次性取出
3. polymorphism=“explicit”,只取出当前查询对象
八。Hibernate二级缓存
著名的n+1问题:from Child,然后在页面上面显示每个子类的父类信息,就会导致n条对parent表的查询:
select * from parent where id = ?
.......................
select * from parent where id = ?
解决方案
1. eager fetch
2. 二级缓存
九。inverse和二级缓存的关系
当使用集合缓存的情况下:
1. inverse=“false”,通过parent.getChildren()来操作,Hibernate维护集合缓存
2. inverse=“true”,直接对child进行操作,未能维护集合缓存!导致缓存脏数据
3. 双向关联,inverse=“true”的情况下应避免使用集合缓存
十。Hibernate二级缓存是提升web应用性能的法宝
OLTP类型的web应用,由于应用服务器端可以进行群集水平扩展,最终的系统瓶颈总是逃不开数据库访问;
哪个框架能够最大限度减少数据库访问,降低数据库访问压力, 哪个框架提供的性能就更高;针对数据库的缓存策略:
1. 对象缓存:细颗粒度,针对表的记录级别,透明化访问,在不改变程序代码的情况下可以极大提升web应用的性能。对象缓存是ORM的制胜法宝。
2. 对象缓存的优劣取决于框架实现的水平,Hibernate是目前已知对象缓存最强大的开源ORM
3. 查询缓存:粗颗粒度,针对查询结果集,应用于数据实时化要求不高的场合
十一。应用场合决定了系统架构
一、是否需要ORM
Hibernate or iBATIS?
二、采用ORM决定了数据库设计
Hibernate:
倾向于细颗粒度的设计,面向对象,将大表拆分为多个关联关系的小表,消除冗余column,通过二级缓存提升性能(DBA比较忌讳关联关系的出现, 但是 ORM的缓存将突破关联关系的性能瓶颈);Hibernate的性能瓶颈不在于关联关系,而在于大表的操作
iBATIS:
倾向于粗颗粒度设计,面向关系,尽量把表合并,通过表column冗余,消除关联关系。无有效缓存手段。iBATIS的性能瓶颈不在于大表操作,而在于关联关系。
总结:
性能口诀
1、使用双向一对多关联,不使用单向一对多
2、灵活使用单向多对一关联
3、不用一对一,用多对一取代
4、配置对象缓存,不使用集合缓存
5、一对多集合使用Bag,多对多集合使用Set
6、继承类使用显式多态
7、表字段要少,表关联不要怕多,有二级缓存撑腰
最近开始留意项目中的Hibernate的性能问题,希望可以抽出时间学习一下hiberante的性能优化。主要是对数据库连接池技术、hibernate二级缓存、hibernate的配置优化等问题进行学习!
1.关联关系:
普通的关联关系:是不包括一个连接表,也就是中间表如:
create table Person(personId bigint not null primary key,addressId bigint not null)
create table Address(addressId bigint not null primary key)
也就是不会还有一个关系表如:
create table Person(personId bigint not null primary key)
create table Address(addressId bigint not null primary key)
create table PersonAddress(personId bigint not null,ddressId bigint not null primary key)
单向many-to-one关联是最常见的,而单向one-to-many是不常见的
2. inner join (内连接)
left (outer) join (左外连接)
right (outer) join (右外连接)
full join (全连接,并不常用)
3.小技巧:
统计结果数目:
(Integer)session.iterator("select count(*) from ..").next()).intValue();
根据一个集合大小来排序:
select user.id,user.name
from User as user.name
left join user.messages msg
group by user.id,user.name
having count(msg)>=1
在 处理大数据量时,会有大量的数据缓冲保存在 Session 的一级缓存中,这缓存大太时会严重显示性能,所以在使用 Hibernate 处理大数据量的,可以使用 session.clear() 或者 session. Evict(Object) 在处理过程中,清除全部的缓存或者清除某个对象。
2) 对大数据量查询时,慎用 list() 或者 iterator() 返回查询结果,
1. 使用 List() 返回结果时, Hibernate 会所有查询结果初始化为持久化对象,结果集较大时,会占用很多的处理时间。
2. 而使用 iterator() 返回结果时,在每次调用 iterator.next() 返回对象并使用对象时, Hibernate 才调用查询将对应的对象初始化,对于大数据量时,每调用一次查询都会花费较多的时间。当结果集较大,但是含有较大量相同的数据,或者结果集不是全部都会使 用时,使用 iterator() 才有优势。
3. 对于大数据量,使用 qry.scroll() 可以得到较好的处理速度以及性能。而且直接对结果集向前向后滚动。
3) 对于关联操作, Hibernate 虽然可以表达复杂的数据关系,但请慎用,使数据关系较为简单时会得到较好的效率,特别是较深层次的关联时,性能会很差。
4) 对含有关联的 PO (持久化对象)时,若 default-cascade="all" 或者 “save-update” ,新增 PO 时,请注意对 PO 中的集合的赋值操作,因为有可能使得多执行一次 update 操作。
5) 在一对多、多对一的关系中,使用延迟加载机制,会使不少的对象在使用时 才 会初始化,这样可使得节省内存空间以及减少数据库的负荷,而且若 PO 中的集合没有被使用时,就可减少互数据库的交互从而减少处理时间。
6) 对于大数据量新增、修改、删除操作或者是对大数据量的查询,与数据库的交互次数是决定处理时间的最重要因素,减少交互的次数是提升效率的最好途径,所以在 开发过程中,请将 show_sql 设置为 true ,深入了解 Hibernate 的处理过程,尝试不同的方式,可以使得效率提升。
7) Hibernate 是以 JDBC 为基础 ,但是 Hibernate 是对 JDBC 的优化,其中使用 Hibernate 的缓冲机制会使性能提升,如使用二级缓存以及查询缓存,若命中率较高明,性能会是到大幅提升。
8) Hibernate 可以通过设置 hibernate.jdbc.fetch_size , hibernate.jdbc.batch_size 等属性,对 Hibernate 进行优化。
9) 不过值得注意的是,一些数据库提供的主键生成机制在效率上未必最佳,大量并发 insert 数据时可能会引起表之间的互锁。数据库提供的主键生成机制,往往是通过在一个内部表中保存当前主键状态(如对于自增型主键而言,此内部表中就维护着当前的 最大值和递增量),之后每次插入数据会读取这个最大值,然后加上递增量作为新记录的主键,之后再把这个新的最大值更新回内部表中,这样,一次 Insert 操作可能导致数据库内部多次表读写操作,同时伴随的还有数据的加锁解锁操作,这对性能产生了较大影响。
因此,对于并发 Insert 要求较高的系统,推荐采用 uuid.hex 作为主键生成机制。
10) Dynamic Update 如果选定,则生成 Update SQL 时不包含未发生变动的字段属性,这样可以在一定程度上提升 SQL 执行效能 . Dynamic Insert 如果选定,则生成 Insert SQL 时不包含未发生变动的字段属性,这样可以在一定程度上提升 SQL 执行效能。
11) 在编写代码的时候请,对将 POJO 的 getter/setter 方法设定为 public ,如果设定为 private , Hibernate 将无法对属性的存取进行优化,只能转而采用传统的反射机制进行操作,这将导致大量的性能开销(特别是在 1.4 之前的 Sun JDK 版本以及 IBM JDK 中,反射所带来的系统开销相当可观)。
12) 在 one-to-many 关系中,将 many 一方设为主动方( inverse=false )将有助性能的改善。
13) 由于多对多关联的性能不佳(由于引入了中间表,一次读取操作需要反复数次查询),因此在设计中应该避免大量使用。
14) Hibernate 支持两种锁机制:即通常所说的“悲观锁( Pessimistic Locking )”和“乐观锁( Optimistic Locking )”。 悲观锁带来数据库性能的大量开销,特别是对长事务而言,这样的开销往往无法承受。乐观锁机制在一定程度上解决了这个问题.乐观锁机制避免了长事务中的数据 库加锁开销,大大提升了大并发量下的系统整体性能表现。
[转]Hibernate性能优化
最新推荐文章于 2023-08-10 14:56:26 发布