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
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 )”。 悲观锁带来 数据库性能的大量开销,特别是对长事务而言,这样的开销往往无法承受。乐观锁机制在一定程度上解决了这个问题.乐观锁机制避免了长事务中的数据库加锁开销,大大提升了大并发量下的系统整体性能表现。
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Java类中有继承关系,相应的在hibernate中,也有继承关系,子类反应到数据库中,就有多种实现形式了,子类和父类可以映射到同一张表中,子类也可以单独映射成一张表,但是用不同的标签实现,子类表和父类表的关系也不同。在映射文件中,有三个标签可以实现继承关系,分别是:subclass、joined-subclass、union-subclass,先陈述一下这三个标签的区别:
subclass标签就是为子类嵌入父类的表中而设计的,而且要指定鉴别器,即用subclass一定要有判断类型的一个列,鉴别器指定记录属于哪个类型。但是subclass也提供了为子类设置单独的表的功能,即join标签。但是不管是内嵌表还是外部表,都得指定鉴别器。
joined-subclass标签,提供的功能是只能为子类设定外部表,而且没有鉴别器,即子类一张表,父类一张表,子类以父类的主键为外键。父类对应的表中,没有判断类型的列。
注意:这两个标签不能混用,若是只想要内嵌表,或者是既想要有内嵌表,又想要外部表,又或者是只想要外部表,那么只能使用subclass标签,需要注意的是,不论哪种方式,都要指定鉴别器,即父类对应的表中,一定有一个判断类型的列;而若是只想要外部表,又不想在父类对应的表中,要那个判断类型的列,那么只能使用join-subclass
union-subclass是将父类中的属性,添加到子类对应的表中去了。包括父类中的外键。union-class和前两个的区别就在于外键的不同,前两个标签,如果子类有单独对应的表的话,这个表的外键是其父类中的主键,而使用union-class,子类对应的表中的外键则和父类的外键是一样的,因为子类把父类继承的属性,也加到了自己的表当中。这样子类和父类的地位就相当了。不过这不是一种好的理解方式。如果是这样的话,那么就可以把父类设为抽象的类,并且在映射文件中,把父类设置为abstract="true",那么就不会再数据库中生成父类对应的表了,父类就只起到一个抽象的作用了。
下面列举员工和部门的例子说明,假设员工类还有两个子类:一个是技术人员,一个是销售人员:
public class Employee { private int id; private String name; private Department depart; ……//set/get方法 }
public class Skiller extends Employee { private String skill; ……//set/get方法 }
public class Saler extends Employee { private String sale; private int age; ……//set/get方法 }
public class Department { private int id; private String name; private Set<Employee> emps; ……//set/get方法 }
部门类的映射文件:
<class name="Department"> <id name="id"> <generator class="native"/> </id> <property name="name"/> <set name="emps" inverse="true"> <key column="depart_id"/> <one-to-many class="Employee"/> </set> </class>
(1)下面关键是员工类的映射文件,我们先来看使用subclass标签的情况:
<class name="Employee" discriminator-value="0"> <id name="id"> <generator class="native"/> </id> <discriminator column="type" type="int"/><!-- 指定了鉴别器 --> <property name="name"/> <many-to-one name="depart" column="depart_id"/> <subclass name="Skiller" discriminator-value="1"> <property name="skill"/> </subclass> <subclass name="Saler" discriminator-value="2"> <property name="sale"/> </subclass> </class>
这种情况就是所谓的将整个继承树映射到同一个表当中,即子类的信息,全部映射到了父类对应的表中。注意,一定要指定鉴别器,它的作用是在父类的映射表中,添加了一个type的列,用来鉴别员工是属于哪个子类,并且在每个类的标签中要指定鉴别器值,如上例中用0表示是普通的员工,用1表示技术人员,用2表示销售人员。我们可以看看创建表的ddl语句:
CREATE TABLE `employee` ( `id` int(11) NOT NULL, `type` int(11) NOT NULL, `name` varchar(255) DEFAULT NULL, `depart_id` int(11) DEFAULT NULL, `skill` varchar(255) DEFAULT NULL, `sale` varchar(255) DEFAULT NULL, PRIMARY KEY (`id`), KEY `FK4AFD4ACE972E0614` (`depart_id`), CONSTRAINT `FK4AFD4ACE972E0614` FOREIGN KEY (`depart_id`) REFERENCES `department` (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=gbk
用这种方式有缺点有优点,缺点是在表中,会有很多的空值,假如又有了新的子类,那么就要修改表的结构,并且相应的空值会更多;优点是所有信息整合到一张表中,查询的效率高。
下面再来看subclass标签的第二种用法:
<class name="Employee" discriminator-value="0"><!-- discriminator-value="0" --> <id name="id"> <generator class="native"/> </id> <discriminator column="type" type="int"/><!-- 指定了鉴别器 --> <property name="name"/> <many-to-one name="depart" column="depart_id"/> <subclass name="Skiller" discriminator-value="1"> <property name="skill"/> </subclass> <subclass name="Saler" discriminator-value="2"> <join table="saler"> <key column="emp_id"/> <property name="sale"/> </join> </subclass> </class>
改变的地方,主要是Saler类的标签,在subclass标签中用join标签,这样就为Saler子类单独映射了一个saler表,其主键为父类对应的表的主键。而Skiller类还是和父类映射到了一张表中。来看看Saler创建表的ddl语句:
CREATE TABLE `saler` ( `emp_id` int(11) NOT NULL, `sale` varchar(255) DEFAULT NULL, PRIMARY KEY (`emp_id`), KEY `FK682490B3F739201` (`emp_id`), CONSTRAINT `FK682490B3F739201` FOREIGN KEY (`emp_id`) REFERENCES `employee` (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=gbk
需要注意的一个地方是这个表的外键,外键和主键是一样的,都是父类表的主键。
(2)joined-subclass的使用
<class name="Employee"><!-- discriminator-value="0" --> <id name="id"> <generator class="native"/> </id> <property name="name"/> <many-to-one name="depart" column="depart_id"/> <joined-subclass name="Skiller" table="skiller"> <key column="emp_id"/> <property name="skill"/> </joined-subclass> <joined-subclass name="Saler" table="saler"> <key column="emp_id"/> <property name="sale"/> </joined-subclass> </class>
用joined-subclass只能创建为子类单独创建表,子类对应的表的主键和外键都是其父类的主键。注意,joined-subclass不能和subclass混合使用。
(3)union-subclass的使用
<class name="Employee"> <id name="id"> <generator class="hilo"/> </id> <property name="name"/> <many-to-one name="depart" column="depart_id"/> <union-subclass name="Skiller" table="skiller"> <property name="skill"/> </union-subclass> <union-subclass name="Saler" table="saler"> <property name="age"/> <property name="sale"/> </union-subclass> </class>
注意,这里主键的生成方式就不能是自增的了,这里用的hilo方式,可以为子类的表分配和父类的表不同的主键。这样每个子类生成了一个表,并且结合了父类中的属性。生成的表的ddl语句为:
CREATE TABLE `skiller` ( `id` int(11) NOT NULL, `name` varchar(255) DEFAULT NULL, `depart_id` int(11) DEFAULT NULL, `skill` varchar(255) DEFAULT NULL, PRIMARY KEY (`id`), KEY `FK4AFD4ACE972E06147ffd86be` (`depart_id`), CONSTRAINT `FK4AFD4ACE972E06147ffd86be` FOREIGN KEY (`depart_id`) REFERENCES `department` (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=gbk
注意,这里的外键是部门类对应的表的主键,这是和上面两个标签的区别之处。若是将父类设置为抽象类,并且在class标签中设置abstract="true",那么父类就不会生成对应的表了。