对IBatis的Cache设计的一点看法

前两天，又看了一下原作《IBatis in Action》，对缓存(Cache)一节又仔细阅读了一次，感觉 IBatis 的 Cache 设计有点鸡肋的感觉，企业级应用基本不会采用。

1. 缓存什么？
   书中写道，一般ORM框架，如Hibernate等，采用对象缓存，而IBatis采用的是简单查询缓存。
   简单 query 缓存，意即:
    cache.key = sql语句串
    cache.value = 查询结果记录集合(List等)
   对于一条 映射sql语句，执行时其条件值的集合，理论上是一个无限集，至少条件集会非常大。因此 sql + 条件值的组合数量非常庞大，按结果集合作为 cache.value 的方式缓存，可以预计，内存消耗非常巨大。

   从缓存的对象来讲，Hibernate 等的两级缓存是一种更好的设计( session级缓存属于第一种 )。
   对象缓存(Object Cache)，将对象像库表记录一样，按主键进行缓存，相当于建立一个简单的内存数据库；
   查询缓存(Query Cache), 与 IBatis 的缓存所指相同，但它只缓存结果集的主键，因此 cache.value 空间消耗大大减少。

   这样对比可见，IBatis 的Cache 不太适合数据量庞大的企业级应用，大型网站应用。

2. 缓存到哪儿？
   应该说，如果 IBatis没有提供对 OSCache 的默认支持，那么IBatis的Cache仅仅适合单机部署的小型应用。
   但 OSCache 作为分布式缓存的一种，在实际应用中仅占不大的比例。

   对于集群部署的大型应用，如果 IBatis 能提供对 Whalin Memached, Spy Memcached,Coherence 等提供支持，将是一种更好的选择。
   幸好，IBatis 还提供了 Cache 的扩展点，可以集成自定义的 Cache 方案。 ^_^

评论

9 楼 C_J 2010-04-28  

竟然偶然做了一次挖坟党！！ 而且还有当年自己的回复，汗一个！！当年自己完全都不懂啊~~ 又汗一个！！
还是继续补充下吧

引用

因此 sql + 条件值的组合数量非常庞大，按结果集合作为 cache.value 的方式缓存，可以预计，内存消耗非常巨大。

**对于按照SQL语句作为key，很正常，hibernate也是这样做。
**如果你对动态SQL的查询结果也使用缓存，也就当然会产生多个数据拷贝，甚至冗余。
**对于记录>1000条，应该不太推荐用缓存，一个大数据量表使用缓存，必定会撑死内存。

引用

对象缓存(Object Cache)，将对象像库表记录一样，按主键进行缓存，相当于建立一个简单的内存数据库；
查询缓存(Query Cache), 与 IBatis 的缓存所指相同，但它只缓存结果集的主键，因此 cache.value 空间消耗大大减少。

**其实你想过为什么ibatis没有“对象缓存”的概念呢？原因就是ibatis映射的是resultClass 和paramClass，而不是基于表的映射，对于ibatis，查询缓存就是对象缓存。

**正因为不需要对象缓存，所以value自然是resultClass的值了，而非id，其实hibernate和ibatis一样也需要那么多内存的。

8 楼 raymond2006k 2009-10-09  

C_J 写道

H是重量级组件
IBATIS是轻量级组件

设计重点也不同;

引用

IBatis 的Cache 不太适合数据量庞大的企业级应用，大型网站应用。

关于这点,反驳的理由:
以下是目前一些大型网站用了IBATIS:
...

用 IBatis，和直接用 IBatis自身的Cache 不是一个概念。
我们的大型网站也用的是 IBatis 作为持久化方案。而自身提供的Cache比较弱，且禁止使用的，主要用的是 Memcached 缓存。

7 楼 raymond2006k 2009-10-09  

lovit 写道

对象缓存与对象池有什么关系呢，什么时候用对象缓存，什么时候用对象池？谢谢！

这里说的“对象缓存”是对持久化的数据对象缓存，按主键值将其缓存到内存。

与一般所说的Java对象缓存及对象池(Object Pool)不是一回事，本帖不涉及此话题。

6 楼 C_J 2009-10-01  

H是重量级组件
IBATIS是轻量级组件

设计重点也不同;

引用

IBatis 的Cache 不太适合数据量庞大的企业级应用，大型网站应用。

关于这点,反驳的理由:
以下是目前一些大型网站用了IBATIS:

Some public websites that utilize IBatis

1up.com - Gaming community  
http://www.1up.com  
Abebooks.com - Worlds largest online marketplace for books  http://www.abebooks.com  
AccesStream.com - Open Source Identity and Access Management Suite  http://www.accesstream.com  
BullionVault.com - Online gold trading  http://www.bullionvault.com  
www.druckdiskont.at - Online print portal (Web To Print)  http://www.druckdiskont.at  
Fiskars - Consumer products manufacturer 
 http://www.fiskars.com  
GalMarley.com - Gold prices, facts, figures and charts  http://www.galmarley.com  
GAPay - General Agent Payment System  
http://www.gapay.com.  
Ideal Financial Services  
http://www.idealfsi.com  ....

于是也简单查了下IBATIS的Cache源码;

- 三种模式

/**
   * Constant for weak caching
   * This cache model is probably the best choice in most cases. It will increase
   * performance for popular results, but it will absolutely release the memory to
   * be used in allocating other objects, assuming that the results are not currently
   * in use.
   */
  public final static MemoryCacheLevel WEAK;

  /**
   * Constant for soft caching.
   * This cache model will reduce the likelihood of running out of memory in case the
   * results are not currently in use and the memory is needed for other objects.
   * However, this is not the most aggressive cache-model in that regard. Hence,
   * memory still might be allocated and unavailable for more important objects.
   */
  public final static MemoryCacheLevel SOFT;

  /**
   * Constant for strong caching.
   * This cache model will guarantee that the results stay in memory until the cache
   * is explicitly flushed. This is ideal for results that are:
   * <ol>
   * <li>very small</li>
   * <li>absolutely static</li>
   * <li>used very often</li>
   * </ol>
   * The advantage is that performance will be very good for this particular query.
   * The disadvantage is that if the memory used by these results is needed, then it
   * will not be released to make room for other objects (possibly more important
   * objects).
   */
  public final static MemoryCacheLevel STRONG;

- 4种策略

FIFO
LRU
MEMORY
OS

-至于楼主提出的存储每条记录,这个一下子也没查到

-关于"内存消耗"这个问题,是以存储的数据单元的大小决定的,总内存=单元数据大小*个数  ,而这个"个数"完全有用户由设定,我觉得存储整条记录和存储主键,各有各的优势..

5 楼 whaosoft 2009-09-30  

呃 和hibernate比是差很多~~ 连memcache 都不支持 ?

4 楼 lnaigg 2009-09-29  

ibatis跟hibernate的运行机制完全不同，它们的缓存机制也是没有可比性的。
可以这样说，ibatis不可能做到基于对象的缓存。


至于集群缓存，那是很简单的事情。

3 楼 matt.u 2009-09-28  

1、iBATIS的缓存机制自己扩展一下就能支持memcache了。

2、其实个人觉得iBATIS的简单查询缓存策略还更灵活一些。
如果你想像Hibernate那样缓存，也可以把一个查询分成两部分，将一个查询分成N+1个查询，也可以像Hibernate那样缓存。

应该也够用了。

2 楼 lovit 2009-09-28  

对象缓存与对象池有什么关系呢，什么时候用对象缓存，什么时候用对象池？谢谢！

1 楼 Foxswily 2009-09-28  

兄台描绘的场景是iBatis在企业应用时(尤其是大数据量)使用缓存。认为存在的瓶颈是大量数据集(cache.value)的存储。窃以为这是混淆了企业级数据应用与轻量级缓存的概念。此处大数据集势必需要独立的缓存服务(至少是文件缓存)而不是单纯的内存缓存，由此出发，很多后续问题可以针对具体业务具体部署，iBatis只负担在缓存miss时与DB交互，这样是不是更纯粹呢。