hibernate

来源:互联网 发布:社区app软件 编辑:程序博客网 时间:2024/05/16 15:52

Hibernate是一个开放源代码的对象关系映射框架,它对JDBC进行了非常轻量级的对象封装,使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库。Hibernate可以应用在任何使用JDBC的场合,既可以在Java的客户端程序使用,也可以在Servlet/JSP的Web应用中使用,最具革命意义的是,Hibernate可以在应用EJB的J2EE架构中取代CMP,完成数据持久化的重任。

基本简介/hibernate

大多数应用程序都需要处理数据。Java应用程序运行时,往往把数据封装为相互连接的对象网络,但是当程序结束时,这些对象就会消失在一团逻辑中,所以需要有一些保存它们的方法。有时候,甚至在编写应用程序之前,数据就已经存在了,所以需要有读入它们和将其表示为对象的方法。手动编写代码来执行这些任务不仅单调乏味、易于出错,而且会占用整个应用程序的很大一部分开发工作量。

优秀的面向对象开发人员厌倦了这种重复性的劳动,他们开始采用通常的“积极”偷懒做法,即创建工具,使整个过程自动化。对于关系数据库来说,这种努力的最大成果就是对象/关系映射(ORM)工具。

这类工具有很多,从昂贵的商业产品到内置于J2EE中的EJB标准。然而,在很多情况下,这些工具具有自身的复杂性,使得开发人员必须学习使用它们的详细规则,并修改组成应用程序的类以满足映射系统的需要。由于这些工具为应付更加严格和复杂的企业需求而不断发展,于是在比较简单和常见的场景中,使用它们所面临的复杂性反而盖过了所能获得的好处。这引起了一场革命,促进了轻量级解决方案的出现,而Hibernate就是这样的一个例子。

核心接口/hibernate

ibernate的核心接口一共有5个,分别为:Session、SessionFactory、Transaction、Query和Configuration。这5个核心接口在任何开发中都会用到。通过这些接口,不仅可以对持久化对象进行存取,还能够进行事务控制。下面对这五的核心接口分别加以介绍。

Session接口:Session接口负责执行被持久化对象的CRUD操作(CRUD的任务是完成与数据库的交流,包含了很多常见的SQL语句。)。但需要注意的是Session对象是非线程安全的。同时,Hibernate的session不同于JSP应用中的HttpSession。这里当使用session这个术语时,其实指的是Hibernate中的session,而以后会将HttpSesion对象称为用户session。

SessionFactory接口:SessionFactroy接口负责初始化Hibernate。它充当数据存储源的代理,并负责创建Session对象。这里用到了工厂模式。需要注意的是SessionFactory并不是轻量级的,因为一般情况下,一个项目通常只需要一个SessionFactory就够,当需要操作多个数据库时,可以为每个数据库指定一个SessionFactory。

Configuration接口:Configuration接口负责配置并启动Hibernate,创建SessionFactory对象。在Hibernate的启动的过程中,Configuration类的实例首先定位映射文档位置、读取配置,然后创建SessionFactory对象。

Transaction接口:Transaction接口负责事务相关的操作。它是可选的,开发人员也可以设计编写自己的底层事务处理代码。

Query和Criteria接口:Query和Criteria接口负责执行各种数据库查询。它可以使用HQL语言或SQL语句两种表达方式。

主键介绍/hibernate

Assigned:Assigned方式由程序生成主键值,并且要在save()之前指定否则会抛出异常。

特点:主键的生成值完全由用户决定,与底层数据库无关。用户需要维护主键值,在调用session.save()之前要指定主键值。

Hilo:Hilo使用高低位算法生成主键,高低位算法使用一个高位值和一个低位值,然后把算法得到的两个值拼接起来作为数据库中的唯一主键。Hilo方式需要额外的数据库表和字段提供高位值来源。默认请况下使用的表是hibernate_unique_key,默认字段叫作next_hi。next_hi必须有一条记录否则会出现错误。

特点:需要额外的数据库表的支持,能保证同一个数据库中主键的唯一性,但不能保证多个数据库之间主键的唯一性。Hilo主键生成方式由Hibernate维护,所以Hilo方式与底层数据库无关,但不应该手动修改hi/lo算法使用的表的值,否则会引起主键重复的异常。

Increment:Increment方式对主键值采取自动增长的方式生成新的主键值,但要求底层数据库的支持Sequence。如Oracle,DB2等。需要在映射文件xxx.hbm.xml中加入Increment标志符的设置。

特点:由Hibernate本身维护,适用于所有的数据库,不适合多进程并发更新数据库,适合单一进程访问数据库。不能用于群集环境。

hibernatehibernate图册
Identity:Identity当时根据底层数据库,来支持自动增长,不同的数据库用不同的主键增长方式。

特点:与底层数据库有关,要求数据库支持Identity,如MySQl中是auto_increment,SQLServer中是Identity,支持的数据库有MySql、SQLServer、DB2、Sybase和HypersonicSQL。Identity无需Hibernate和用户的干涉,使用较为方便,但不便于在不同的数据库之间移植程序。

Sequence:Sequence需要底层数据库支持Sequence方式,例如Oracle数据库等。

特点:需要底层数据库的支持序列,支持序列的数据库有DB2、PostgreSql、Qracle、SAPDb等在不同数据库之间移植程序,特别从支持序列的数据库移植到不支持序列的数据库需要修改配置文件。

Native:Native主键生成方式会根据不同的底层数据库自动选择Identity、Sequence、Hilo主键生成方式。

特点:根据不同的底层数据库采用不同的主键生成方式。由于Hibernate会根据底层数据库采用不同的映射方式,因此便于程序移植,项目中如果用到多个数据库时,可以使用这种方式。

UUID:UUID使用128位UUID算法生成主键,能够保证网络环境下的主键唯一性,也就能够保证在不同数据库及不同服务器下主键的唯一性。

特点:能够保证数据库中的主键唯一性,生成的主键占用比较多的存贮空间。

ForeignGUID:Foreign用于一对一关系中。GUID主键生成方式使用了一种特殊算法,保证生成主键的唯一性,支持SQLServer和MySQL。

源码对照/hibernate

net.sf.hibernate. 
该包的类基本上都是接口类和异常类
net.sf.hibernate.cache. 
JCS的实现类
net.sf.hibernate.cfg. 
配置文件读取类
net.sf.hibernate.collection. 
Hibernate集合接口实现类,例如List,Set,Bag等等,Hibernate之所以要自行编写集合接口实现类是为了支持lazyloading
net.sf.hibernate.connection. 
几个数据库连接池的Provider
net.sf.hibernate.dialect. 
支持多种数据库特性,每个Dialect实现类代表一种数据库,描述了该数据库支持的数据类型和其它特点,例如是否有AutoIncrement,是否有Sequence,是否有分页sql等等
net.sf.hibernate.eg. 
Hibernate文档中用到的例子
net.sf.hibernate.engine. 
这个包的类作用比较散
net.sf.hibernate.expression. 
HQL支持的表达式
net.sf.hibernate.hq. 
HQL实现
net.sf.hibernate.id. 
ID生成器
net.sf.hibernate.impl. 

hibernatehibernate图册
最核心的包,一些重要接口的实现类,如果Session,SessionFactory,Query等
net.sf.hibernate.jca. 
JCA支持,把Session包装为支持JCA的接口实现类
net.sf.hibernate.jmx. 
我不懂JMX,只知道JMX是用来编写AppServer的管理程序的,大概是JMX部分接口的实现,使得AppServer可以通过JMX接口管理Hibernate
net.sf.hibernate.loader. 
也是很核心的包,主要是生成sql语句的
net.sf.hibernate.lob. 
Blob和Clob支持
net.sf.hibernate.mapping. 
hbm文件的属性实现
net.sf.hibernate.metadata. 
PO的Meta实现
net.sf.hibernate.odmg. 
ODMG是一个ORM标准,这个包是ODMG标准的实现类
net.sf.hibernate.persister. 
核心包,实现持久对象和表之间的映射
net.sf.hibernate.proxy. 
hibernatehibernate图册
Proxy和LazyLoading支持
net.sf.hibernate.ps. 
该包是PreparedStatmentCache
net.sf.hibernate.sql. 
生成JDBCsql语句的包
net.sf.hibernate.test. 
测试类,你可以用junit来测试Hibernate
net.sf.hibernate.tool.hbm2ddl. 
用hbm配置文件生成DDL
net.sf.hibernate.transaction. 
HibernateTransaction实现类
net.sf.hibernate.type. 
Hibernate中定义的持久对象的属性的数据类型
net.sf.hibernate.util. 
一些工具类,作用比较散
net.sf.hibernate.xml. 
XML数据绑定。

类库简介/hibernate

antlr(必需):Hibernate使用ANTLR来产生查询分析器,这个类库在运行环境下时也是必需的。

Dom4j(必需):Hibernate使用dom4j解析XML配置文件和XML映射元文件。

cglib,asm(必需):Hibernate在运行时使用这个代码生成库增强类(与JAVA反射机制联合使用)。

CommonsCollections,CommonsLogging(必需):Hibernat使用ApacheJakartaCommons项目提供的多个工具类库。

ehcache(必需):Hibernate可以使用不同cache缓存工具作为二级缓存。EHCache是缺省的cache缓存工具。

Log4j(可选):Hibernate使用CommonsLoggingAPI,它也可以依次使用Log4j作为底层实施log的机制。如果上下文类目录中存在Log4j库,则CommonsLogging使用Log4j和并它在上下文类路径中寻找的log4j.properties文件。你可以使用在Hibernate发行包中包含中的那个示例Log4j的配置文件。这样,把log4j.jar和它的配置文件(位于src/目录中)拷贝到你的上下文类路径下,就可以在后台看到底程序如何运行的。

其他文件是不是必需的:请察看Hibernate发行包中的lib/README.txt文件,这是一个Hibernate发行包中附带的第三方类库的列表,他们总是保持最新的。你可以在那里找到所有必需或者可选的类库(注意:其中的"buildtimerequired"指的是编译Hibernate时所需要而非编译你自己的程序所必需的类库)。

缓存管理/hibernate

Hibernate 中提供了两级Cache,第一级别的缓存是Session级别的缓存,它是属于事务范围的缓存。这一级别的缓存由hibernate管理的,一般情况下无 需进行干预;第二级别的缓存是SessionFactory级别的缓存,它是属于进程范围或群集范围的缓存。这一级别的缓存可以进行配置和更改,并且可以 动态加载和卸载。 Hibernate还为查询结果提供了一个查询缓存,它依赖于第二级缓存。

1. 一级缓存和二级缓存的比较:

第一级缓存 第二级缓存 存放数据的形式

相互关联的持久化对象 对象的散装数据 缓存的范围 事务范围,每个事务都有单独的第一级缓存 进程范围或集群范围,缓存被同一个进程或集群范围内的所有事务共享 并发访问策略 由于每个事务都拥有单独的第一级缓存,不会出现并发问题,无需提供并发访问策略 由于多个事务会同时访问第二级缓存中相同数据,因此必须提供适当的并发访问策略,来保证特定的事务隔离级别 数据过期策略 没有提供数据过期策略。

处于一级缓存中的对象永远不会过期,除非应用程序显式清空缓存或者清除特定的对象 必须提供数据过期策略,如基于内存的缓存中的对象的最大数目,允许对象处于缓存中的最长时间,以及允许对象处于缓存中的最长空闲时间 物理存储介质 内存 内存和硬盘。对象的散装数据首先存放在基于内在的缓存中,当内存中对象的数目达到数据过期策略中指定上限时,就会把其余的对象写入基于硬盘的缓存中。

缓存的软件实现 在Hibernate的Session的实现中包含了缓存的实现 由第三方提供,Hibernate仅提供了缓存适配器(CacheProvider)。用于把特定的缓存插件集成到Hibernate中。 启用缓存的方式 只要应用程序通过Session接口来执行保存、更新、删除、加载和查询数据库数据的操作,Hibernate就会启用第一级缓存,把数据库中的数据以对象的形式拷贝到缓存中,对于批量更新和批量删除操作,如果不希望启用第一级缓存,可以绕过Hibernate API,直接通过JDBC API来执行指操作。 用户可以在单个类或类的单个集合的粒度上配置第二级缓存。如果类的实例被经常读但很少被修改,就可以考虑使用第二级缓存。

只有为某个类或集合配置了第二级缓存,Hibernate在运行时才会把它的实例加入到第二级缓存中。 用户管理缓存的方式 第一级缓存的物理介质为内存,由于内存容量有限,必须通过恰当的检索策略和检索方式来限制加载对象的数目。Session的evit()方法可以显式清空缓存中特定对象,但这种方法不值得推荐。

第 二级缓存的物理介质可以是内存和硬盘,因此第二级缓存可以存放大量的数据,数据过期策略的maxElementsInMemory属性值可以控制内存中的 对象数目。管理第二级缓存主要包括两个方面:选择需要使用第二级缓存的持久类,设置合适的并发访问策略:选择缓存适配器,设置合适的数据过期策略。

2. 一级缓存的管理: 当 应用程序调用Session的save()、update()、savaeOrUpdate()、get()或load(),以及调用查询接口的 list()、iterate()或filter()方法时,如果在Session缓存中还不存在相应的对象,Hibernate就会把该对象加入到第一 级缓存中。当清理缓存时,Hibernate会根据缓存中对象的状态变化来同步更新数据库。 Session为应用程序提供了两个管理缓存的方法:evict(Object obj):从缓存中清除参数指定的持久化对象。 clear():清空缓存中所有持久化对象。

3. 二级缓存的管理:

3.1. Hibernate的二级缓存策略的一般过程如下:

1) 条件查询的时候,总是发出一条select * from table_name where …. (选择所有字段)这样的SQL语句查询数据库,一次获得所有的数据对象。

2) 把获得的所有数据对象根据ID放入到第二级缓存中。

3) 当Hibernate根据ID访问数据对象的时候,首先从Session一级缓存中查;查不到,如果配置了二级缓存,那么从二级缓存中查;查不到,再查询数据库,把结果按照ID放入到缓存。

4) 删除、更新、增加数据的时候,同时更新缓存。   

Hibernate的二级缓存策略,是针对于ID查询的缓存策略,对于条件查询则毫无作用。为此,Hibernate提供了针对条件查询的Query Cache。

3.2. 什么样的数据适合存放到第二级缓存中? 1 很少被修改的数据 2 不是很重要的数据,允许出现偶尔并发的数据 3 不会被并发访问的数据 4 参考数据,指的是供应用参考的常量数据,它的实例数目有限,它的实例会被许多其他类的实例引用,实例极少或者从来不会被修改。

3.3. 不适合存放到第二级缓存的数据? 1 经常被修改的数据 2 财务数据,绝对不允许出现并发 3 与其他应用共享的数据。

3.4. 常用的缓存插件 Hibernater 的二级缓存是一个插件,下面是几种常用的缓存插件:

l EhCache:可作为进程范围的缓存,存放数据的物理介质可以是内存或硬盘,对Hibernate的查询缓存提供了支持。

l OSCache:可作为进程范围的缓存,存放数据的物理介质可以是内存或硬盘,提供了丰富的缓存数据过期策略,对Hibernate的查询缓存提供了支持。

l SwarmCache:可作为群集范围内的缓存,但不支持Hibernate的查询缓存。

l JBossCache:可作为群集范围内的缓存,支持事务型并发访问策略,对Hibernate的查询缓存提供了支持。

3.5. 配置二级缓存的主要步骤:

1) 选择需要使用二级缓存的持久化类,设置它的命名缓存的并发访问策略。这是最值得认真考虑的步骤。

2) 选择合适的缓存插件,然后编辑该插件的配置文件。

程序性能优化/hibernate

对于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,在进行大批数据更新时,BATCH与不使用BATCH有效率上也有很大的差别。我们可以通过设置batch_size来让其支持批量操作。

举个例子,要批量删除某表中的对象,如“delete Account”,打出来的语句,会发现HIBERNATE找出了所有ACCOUNT的ID,再进行删除,这主要是为了维护二级缓存,这样效率肯定高不了,在后续的版本中增加了bulk delete/update,但这也无法解决缓存的维护问题。


0 0
原创粉丝点击