码迷,mamicode.com
首页 > Web开发 > 详细

NHibernate N+1问题实例分析和优化

时间:2015-08-28 19:34:30      阅读:271      评论:0      收藏:0      [点我收藏+]

标签:

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

NHibernate N+1问题实例分析和优化

标签:

原文地址:http://www.cnblogs.com/chenmoit/p/4767031.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!