1.问题的缘起
考察下面的类结构定义
public class Category
{
string _id;
Category _parent;
IList<Category> _children = new List<Category>();
public virtual string Id
{
get
{
return _id;
}
}
public virtual Category Parent
{
get
{
return _parent;
}
}
public virtual IList<Category> Children
{
get
{
return _children;
}
}
public virtual string Title
{
get;
set;
}
public virtual string ImageUrl
{
get;
set;
}
public virtual int DisplayOrder
{
get;
set;
}
}
其Nhibernate映射文件的内容为：
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2">
<class name="Category">
<id name="Id" access="nosetter.camelcase-underscore" length="32">
<generator class="uuid.string"/>
</id>
<property name="Title" not-null="true" length="50"/>
<property name="ImageUrl" length="128"/>
<property name="DisplayOrder" not-null="true"/>
<many-to-one name="Parent" class="Category" column="ParentId" access="nosetter.camelcase-underscore"/>
<bag name="Children" access="nosetter.camelcase-underscore" cascade ="all-delete-orphan" inverse="true" order-by="DisplayOrder ASC">
<key column="ParentId"/>
<one-to-many class="Category"/>
</bag>
</class>
</hibernate-mapping>
当程序中要求“筛选出所有Category，再依次遍历其下的Children中的子对象”时，通常，我们会写出如下符合要求的代码：
var query = from o in CurrentSession.QueryOver<Category>() select o;
IList<Category> list = query.List(); //第一级查询
foreach (Category item in list)
{
foreach (Category child in item.Children) //第二级查询
{
//...
}
}
这段代码运行正常，输出的SQL语句类似于：
--第一级查询
Select * From [Category]
--第二级查询(每次参数都不同)
Select * From [Category] Where [ParentId]=@p0
Select * From [Category] Where [ParentId]=@p0
.......
Select * From [Category] Where [ParentId]=@p0
从输出的SQL可以看出，上面的代码隐藏着严重的性能问题。假设第一级查询返回20个Category对象保存到list列表中，而每个Category中又包含10个子对象，那么两个foreach循环执行下来，共需要向数据库发送20*10=200条Select查询语句。对于list列表中的每个Category来说，从数据库中取出其本身需要执行一条Select语句（即第一级查询），查询其下的子元素需要执行10条Select语句，也就是说从取出Category到遍历完其所有子对象，需要执行N+1条Select语句，N是子对象的个数，这就是所谓的“N+1”问题，它最大的弊端显而易见，在于向数据库发送了过多的查询语句，造成不必要的开销，而通常情况下这是可以优化的。
2.解决方案
2.1 批量加载
由于“N+1”问题是发送了过多的Select语句，首先就会想到，能不能把这些语句合并在一次数据库查询中，为了解决这个问题，Nhibernate在集合映射中，提供了“批量加载”策略，即：batch-size，经改造后的bag映射如下：
<bag name="Children" access="nosetter.camelcase-underscore" cascade ="all-delete-orphan" inverse="true" order-by="DisplayOrder ASC" batch-size="20">
<key column="ParentId"/>
<one-to-many class="Category"/>
</bag>
batch-size表明Category.Children列表装载时，每次读取20个子对象，而不是一个一个加载。因此，N+1就演变成N/20+1。对于上文的两个foreach过程，输出的SQL语句类似于：
--第一级查询
Select * From [Category]
--第二级查询
Select * From [Category] Where [ParentId] In (@p0,@p1....@p19)
对比未采用“批量加载”策略的SQL输出，显然新的解决方案能够极大的减少向数据库发送查询语句。
如果需要将多有对象加载过程都设置为批量，可以在Nhibernate配置文件中添加default_batch_fetch_size属性，而不需要修改每个类的映射文件。
2.2 预加载
解决“N+1”问题的另一种方法是使用预加载(Eager Fetching)，同样，Nhibernate在集合映射中也提供了对它的支持，即：outer-join或fetch。改造后的bag映射配置如下：
<bag name="Children" access="nosetter.camelcase-underscore" cascade ="all-delete-orphan" inverse="true" order-by="DisplayOrder ASC" outer-join="true">
<key column="ParentId"/>
<one-to-many class="Category"/>
</bag>
outer-join=“true”等效于fetch="join"，而fetch还有“select”和“subselect”两个选项（默认为“select”选项）,他们指的都是用何种SQL语句加载子集合。当outer-join=“true”或fetch="join"时，输出的SQL语句类似于：
--第一级查询
Select t0.Id,t0.ParentId,t0.Title...t1.Id,t1.ParentId,t1.Title... From [Category] t0 Left Join [Category] t1 On t1.ParentId=t0.Id
预加载在第一级查询，就通过Join一次性的取出对象本身及其子对象，比使用批量加载生成的语句还要少，首一次加载效率高。
虽然，在映射文件中启用预加载设置，十分简单，但是考虑到其他方式（如:Get或Load）获取对象时也会自动装载子对象，造成不必要的性能损失，另外，在映射文件中设置预加载，其“作用域”有只适用于：通过Get或Load获取对象、延迟加载（隐式）关联对象、Criteria查询和带有left join fetch的HQL语句，因此通常要求避免将启用预加载的配置写在映射文件里（Nhibernate也不推荐写在映射文件中），而是将其写在需要用到预加载的代码中，其他的地方则保持原有逻辑，这样才不会产生不良影响，预加载在代码里的写法有三种：
ICriteria.SetFetchMode(string associationPath, FetchMode mode);
或者在3.0里面使用的
IQueryOver<TRoot, TSubType>.Fetch(Expression<Func<TRoot, object>> path);
再或者HQL中使用left join fetch
from Category a left join fetch Category b
这里有一个奇特的情况，FetchMode枚举包含Eager和Join两个选项，但实际使用中的效果是一样的，都是输出Join语句，没有任何区别，Nhibernate如此设置，我猜想可能的原因是开始时只有Join一个选项，而后觉得不够贴切，遂增加一个Eager，但考虑到老版本兼容性，没有删除Join，所以就成了现在这个样子。下面的代码说明了在IQueryOver中如何使用预加载
q = q.Fetch(o => o.Children).Eager;
到此为止，一切都显得很完美，不过，还没完，预加载由于其生成的SQL语句包括了Join或子查询语句，因此它无法保证获取到集合中元素的唯一性，例如：A包含两个子元素B和C，那么通过预加载后，第一级查询取出的列表中会包括两个A对象，而不是通常我们想象的一个。所以，启用预加载后获取到的列表，需要手动的解决唯一性的问题，最简单的就是把列表装入ISet里“过滤”一次。
protected IList<T> ToUniqueList(IEnumerable<T> collection)
{
ISet<T> set = new HashSet<T>(collection);
return set.ToList();
}
2.3 混合加载
上面，我们只假设了Category包含子对象只有一层嵌套的情况，然而，如果子对象还有子对象，无限层嵌套时，批量加载和预加载会出现什么情况呢，首先，只采用批量加载的情况下，除第一层外，以下每层嵌套都会采用批量加载的方式，可见第一层加载的效率相对较低，其次，只采用预加载的情况下，第一次使用Join加载，获取到第一层和第二层对象，而第二层往下，每层对象的加载过程又还原到简单的Select上，与本文开头所讲的情形是一摸一样的，因此，多层次加载效率较低。那么把它们结合起来，既在映射文件中设置batch-size，又在代码中开启FetchMode.Eager，会不会综合两种的优势克服不足呢？经过实践，答案是肯定的。同时使用批量加载和预加载的情况下，首次查询时，SQL中出现了Join语句，即预加载起作用，获取到第一层和第二层对象，而后每层的查询，SQL中出现了In语句，也就是批量加载又发挥了作用，我把这种综合运用两种加载方式，结合了各自优点的新方式称为“混合加载”，这是在Nhibernate官方文档里没有的。
3.抓取策略
以上我们谈到的内容，统称为抓取策略（Fetching Strategy）。Nhibernate中，定义了一下几种抓取策略：
- 连接抓取（Join fetching）：通过 在SELECT语句使用OUTER JOIN（外连接）来获得对象的关联实例或者关联集合。
- 查询抓取（Select fetching）：另外发送一条 SELECT 语句抓取当前对象的关联实体或集合（lazy="true"时，这是默认选项）。
- 子查询抓取（Subselect fetching）：另外发送一条SELECT 语句抓取在前面查询到（或者抓取到）的所有实体对象的关联集合。（lazy="true"时）
- 批量抓取（Batch fetching）： 对查询抓取的优化方案， 通过指定一个主键或外键列表，使用单条SELECT语句获取一批对象实例或集合。
另外，Nhibernate抓取策略会区分下列各种情况：
- Immediate fetching，立即抓取：当宿主被加载时，关联、集合或属性被立即抓取。
- Lazy collection fetching，延迟集合抓取：直到应用程序对集合进行了一次操作时，集合才被抓取。（对集合而言这是默认行为。）
- "Extra-lazy" collection fetching,"Extra-lazy"集合抓取：对集合类中的每个元素而言，都是直到需要时才去访问数据库。除非绝对必要，Hibernate不会试图去把整个集合都抓取到内存里来（适用于非常大的集合）。
- Proxy fetching，代理抓取：对返回单值的关联而言，当其某个方法被调用，而非对其关键字进行get操作时才抓取。
- "No-proxy" fetching,非代理抓取：对返回单值的关联而言，当实例变量被访问的时候进行抓取。
- Lazy attribute fetching，属性延迟加载：对属性或返回单值的关联而言，当其实例变量被访问的时候进行抓取。需要编译期字节码强化，因此这一方法很少是必要的。
默认情况下，NHibernate对集合使用延迟select抓取，这对大多数的应用而言，都是有效的，如果需要优化这种默认策略，就需要选择适当的抓取策略，本文第二章列出的具体的可用解决方案。
4.总体原则
上文讲述了Nhibernate的抓取策略和具体解决方案，归结起来，在运用抓取策略提高性能时，总的原则就是：尽量在首次查询或每次查询时多加载关联的集合对象，在合适的地方使用抓取策略，既提高性能，又要影响其他应用场景为好。
谢谢观赏！
参考文献：
1.《NHibernate Reference Documentation 3.0》：http://nhforge.org/doc/nh/en/index.html
2.Pierre Henri Kuaté, Tobin Harris, Christian Bauer, and Gavin King.Nhibernate in Action February, 2009
posted @ 2011-05-09 10:52 DreamTrue 阅读(1349) 评论(3)
编辑