拜读了Robbin的文章《Web应用的缓存设计模式》http://robbinfan.com/blog/38/orm-cache-sumup ,我觉得大体思想还是值得学习和借鉴的,借这机会顺便简单谈谈我一般的做法,基于它文章Blog的例子和场景。

以读取博客文章列表和文章为例

一、数据库设计

首先,从数据库设计上,我赞同Contents拆分出去,在显示列表时,是没必要读取完整内容的。但如果缓存应用得当,这个可以属于可选项,并非必须。按照我的习惯,表设计会如下:

Blogs表,用以存储博客内容
BlogId int 用以存储博客内容,表主键,聚集索引
Title nvarchar(256) 博客标题
Content nvarchar(MAX) 博客内容
FormattedContent nvarchar(MAX) 格式化后博客内容,空间换时间,没必要消耗CPU去格式化markdown。可选项,也可以运算后放缓存
AuthorId   int 和Accounts表关联
Author nvarchar(256) 作者,冗余字段,可以不必查询Accounts表
BlogDate datetime 博客发布时间

补充说明:

1. 适当冗余,例如FormattedContent和Author字段,减少跨表查询或CPU运算
2. Content和FormattedContent字段可以考虑分离到另一个表纵向拆分,但并非必要选项,这里我没有分开,尽可能在一起
3. 该表可以用非关系数据库如Key-Value数据库存储,当数据增大可以根据BlogId进行合理分区,这样可以避免单表过大影响查询效率。对WindowsAzure了解的可参考TableStorage。

光这个表,博客的内容是都有了,但要达到比较高的效率,我还会根据业务场景建立几个“索引表”,举两个业务场景:1,首页分页浏览博客文章列表 2,根据Tag检索博客文章,这两个场景会对应两个“索引表”,如下所示:

BlogList表,存储博客列表信息
BlogId int 博客Id,和Blogs表的BlogId关联,主键,非聚集索引
BlogDate   datetime 博客发布时间,和Blogs表的BlogDate一致,聚集索引
     

 

TagBlogs表,纪录Tag和Blog的对应关系
Tag   nvarchar(64) Tag字段。和BlogId字段形成双主键,非聚集索引
BlogId int 博客Id,和Blogs表的BlogId关联
BlogDate datetime 博客发布时间,和Blogs表的BlogDate一致。Tag和BlogDate作为聚集索引

补充说明:
1. 所谓索引表,其实功能和索引类似的,就是根据查询条件查出来实体对象主键(BlogId)。
2. 聚集索引尽量建立在查询条件上,以尽可能提高检索效率
3. 对于性能要求高的查询单独索引表
4. 对索引表的查询结果为满足条件主键集合,例如:“select BlogId from BlogList order by BlogDate desc” or "select BlogId from TagBlogs where Tag = @Tag order by BlogDate desc"

表设计基本如此

二、数据库查询

1. 根据id集合返回实体集合,不提供单个id查询。存储过程应该有很多种写法,类似于 “select BlogId, Title, Content, FormattedContent, AuthorId, Author, BlogDate from Blogs where BlogId in (2, 4, 7, 12, 88)”
2. 根据业务场景去查id集合,例如:“select BlogId from BlogList order by BlogDate desc” or "select BlogId from TagBlogs where Tag = @Tag order by BlogDate desc"
3. 涉及分页在内存中完成。例如我要按照时间倒序查所有博客列表,那么根据上面的Sql会得到一个排序好的BlogId集合,转换成内存的一个数组,例如:[100,99,98,97,96....5,4,3,2,1],如果我要现在每页5条纪录,那么第一页的集合就是:[100,99,98,97,96]。然后根据把它作为一个id集合,就可以获取到一个实体集合

这样把数据库查询分成两次,确实有脱裤子放屁之嫌,但结合缓存来看就不会了。

三、缓存

缓存的粒度确实是个非常重要的问题,举例来说,如果按照“SELECT * FROM blogs ORDER BY id DESC LIMIT 20”来查询一页博客数据集合。并将它缓存到内存中,那么如果博客更新频繁(象博客园这样的频度),那么缓存命中率极低,所以我一般会把缓存分成两级。
1. 第一级,id->entity,也就是粒度为单个实体,举博客的例子,就是Key是blogid,Value就是Blog实体对象。这个需要有一个Cache更新、清理的逻辑,有很多成熟方案,不赘述。
2. 第二级,查询条件->ids,也就是查询条件到id集合的一个缓存,举例来说,根据Tag查询博客,那么我会把Tag作为Key,Value则为该Tag下按照时间倒序排列的所有BlogId的集合。这个根据数据更新频度,一般Cache时间很短,这样可以保证数据更新了缓存也会及时更新,并且它都是在索引表查询,数据库查询效率极高。

根据上面二级缓存的设计,缓存命中率会大大提高,例如即使帖子列表更新,一级缓存也不会实效。二级缓存其实只是辅助,但是由于索引表的存在,不用担心查询效率降低对缓存的依赖。

四、综合

综合以上种种,一个结合缓存的数据查询会如下过程(以按照时间倒序分页浏览博客列表为例):

1. 首先根据业务条件去缓存查找id集合,如果缓存没有,就去数据库查询,并将查询结果更新到缓存。假如我获得的id集合为:[100,99,98,97,96....5,4,3,2,1]
2. 根据分页条件,在内存中从返回的所有id集合中获取页id集合,假如页id集合是[100,99,98,97,96]
3. 根据页id集合中的id,去一级缓存中逐一检查缓存是否有数据,过滤掉缓存中有的。例如[100,99,98,97,96]中[100,97,96]三个在Cache中已经存在,那么留下[99,98]
4. 用过滤后的id集合(如果为空跳过该步骤)去数据库中获取实体集合,并将结果加入一级缓存。例如“select BlogId, Title, Content, FormattedContent, AuthorId, Author, BlogDate from Blogs where BlogId in (99,98)”,并将它加入缓存
5. 根据id结合顺序拼合实体集合返回,例如:[blog100,blog99,blog98,blog87,blog96]
6. 如果分页控件需要知道总记录条数,将第一步的总id集合条数返回即可。

从单次查询来看,一次查询分成了两次,效率不高,但是从多次查询请求来看,缓存命中率会非常高,对数据库压力极小,数据库的查询将主要集中在对id集合的查询,但是由于索引表的存在,这个查询性能将极高。

四、总结

以上是我常用的一种数据查询和缓存的方案,由于解释起来较为繁琐,所以一直懒得写,但是实际用下来无论是查询效率还是开发效率都极高效。希望能对大家有所帮助。

另外,这种方案不适用于数据量极大的情况,因为这种情况下获取全部id集合的成本极高,但适合绝大部分应用场景。

本文转自:http://www.cnblogs.com/dotey/archive/2013/03/08/2949153.html