些网络书籍及项目经验整理而成只提供要点和思路具体做法可以留言探讨或是找些更详细更有针对性
资料
初用HIBERNATE
人也许都遇到过性能问题实现同功能用HIBERNATE和用JDBC性能相差十几倍很正常如果不及早调整很可能影响整个项目进度大体上
对于HIBERNATE性能调优主要考虑点如下:Ø 数据库设计调整
Ø HQL优化
Ø API
正确使用(如根据区别业务类型选用区别集合及查询API)Ø 主配置参数(日志
查询缓存Cachefetch_size, batch_size等)Ø 映射文件优化(ID生成策略
2级缓存Cache延迟加载关联优化)Ø
级缓存Cache管理Ø 针对 2级缓存Cache
还有许多特有策略Ø 事务控制策略
1、 数据库设计
a) 降低关联
复杂性b) 尽量不使用联合主键
c) ID
生成机制区别数据库所提供机制并不完全样d) 适当
冗余数据不过分追求高范式2、 HQL优化
HQL如果抛开它同HIBERNATE本身
些缓存Cache机制关联HQL优化窍门技巧同普通SQL优化窍门技巧样可以很容易在网上找到些经验的谈3、 主配置
a) 查询缓存Cache
同下面讲缓存Cache不太样它是针对HQL语句缓存Cache即完全样语句再次执行时可以利用缓存Cache数据但是查询缓存Cache在个交易系统(数据变更频繁查询条件相同机率并不大)中可能会起反作用:它会白白耗费大量系统资源但却难以派上用场b) fetch_size
同JDBC相关参数作用类似参数并不是越大越好而应根据业务特征去设置c) batch_size同上
d) 生产系统中
切记要关掉SQL语句打印4、 缓存Cache
a) 数据库级缓存Cache:这级缓存Cache是最高效和安全
但区别数据库可管理层次并不样比如在ORACLE中可以在建表时指定将整个表置于缓存Cache当中b) SESSION缓存Cache:在
个HIBERNATE SESSION有效这级缓存Cache可干预性不强大多于HIBERNATE自动管理但它提供清除缓存Cache思路方法这在大批量增加/更新操作是有效比如同时增加十万条记录按常规方式进行很可能会发现OutofMemeroy异常这时可能需要手动清除这级缓存Cache:Session.evict以及 Session.clearc) 应用缓存Cache:在
个SESSIONFACTORY中有效因此也是优化重中的重因此各类策略也考虑较多在将数据放入这级缓存Cache的前需要考虑些前提条件:i. 数据不会被第 3方修改(比如
是否有另个应用也在修改这些数据?)ii. 数据不会太大
iii. 数据不会频繁更新(否则使用CACHE可能适得其反)
iv. 数据会被频繁查询
v. 数据不是关键数据(如涉及钱
安全等方面问题)缓存Cache有几种形式
可以在映射文件中配置:read-only(只读适用于很少变更静态数据/历史数据)nonstrict-read- writeread-write(比较普遍形式效率般)transactional(JTA中且支持缓存Cache产品较少)d) 分布式缓存Cache:同c)
配置样只是缓存Cache产品选用区别在目前HIBERNATE中可供选择不多oscache, jboss cache目前大多数项目对它们用于集群使用(特别是关键交易系统)都持保守态度在集群环境中只利用数据库级缓存Cache是最安全5、 延迟加载
a) 实体延迟加载:通过使用动态代理实现
b) 集合延迟加载:通过实现自有
SET/LISTHIBERNATE提供了这方面支持c) 属性延迟加载:
6、 思路方法选用
a) 完成同样
件事HIBERNATE提供了可供选择些方式但具体使用什么方式可能用性能/代码都会有影响显示次返回十万条记录 (List/Set/Bag/Map等)进行处理很可能导致内存不够问题而如果用基于游标(ScrollableResults)或 Iterator结果集则不存在这样问题b) Session
load/get思路方法前者会使用 2级缓存Cache而后者则不使用c) Query和list/iterator
如果去仔细研究下它们你可能会发现很多有意思情况 2者主要区别(如果使用了Spring在HibernateTemplate中对应find,iterator思路方法):i. list只能利用查询缓存Cache(但在交易系统中查询缓存Cache作用不大)
无法利用 2级缓存Cache中单个实体但list查出对象会写入 2级缓存Cache但它般只生成较少执行SQL语句很多情况就是条(无关联)ii. iterator则可以利用 2级缓存Cache
对于条查询语句它会先从数据库中找出所有符合条件记录ID再通过ID去缓存Cache找对于缓存Cache中没有记录再构造语句从数据库中查出因此很容易知道如果缓存Cache中没有任何符合条件记录使用iterator会产生N+1条SQL语句(N为符合条件记录数)iii. 通过iterator
配合缓存Cache管理API在海量数据查询中可以很好解决内存问题如: while(it.hasNext
){
YouObject object = (YouObject)it.next;
session.evict(youObject);
sessionFactory.evice(YouObject.
, 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
在进行大批数据更新时BATCH和不使用BATCH有效率上也有很大差别我们可以通过设置batch_size来让其支持批量操作举个例子
要批量删除某表中对象如“delete Account”打出来语句会发现HIBERNATE找出了所有ACCOUNTID再进行删除这主要是为了维护 2级缓存Cache这样效率肯定高不了在后续版本中增加了bulk delete/update但这也无法解决缓存Cache维护问题也就是说由于有了 2级缓存Cache维护问题HIBERNATE批量操作效率并不尽如人意!从前面许多要点可以看出
很多时候我们是在效率和安全/准确性上找个平衡点无论如何优化都不是个纯技术问题你应该对你应用和业务特征有足够了解般优化方案应在架构设计期就基本确定否则可能导致没必要返工致使项目延期而作为架构师和项目经理(project manager)还要面对开发人员可能抱怨必竟我们对用户需求更改控制力不大但技术/架构风险是应该在初期意识到并制定好相关对策还有
点要注意应用层缓存Cache只是锦上添花永远不要把它当救命稻草应用根基(数据库设计算法高效操作语句恰当API选择等)才是最重要
最新评论