侯体宗的博客
  • 首页
  • Hyperf版
  • beego仿版
  • 人生(杂谈)
  • 技术
  • 关于我
  • 更多分类
    • 文件下载
    • 文字修仙
    • 中国象棋ai
    • 群聊
    • 九宫格抽奖
    • 拼图
    • 消消乐
    • 相册

数据库对象的缓存策略

数据库  /  管理员 发布于 7年前   206
数据库对象的缓存策略

前言
本文探讨Jive(曾经开源的Java论坛)和Hibernate(Java开源持久层)的数据库对象的缓存策略,并阐述作者本人的Lightor(Java开源持久层)采用的数据库对象缓存策略。
本文的探讨基于以前开源的Jive代码,Hibernate2.1.7源码,和作者本人的Lightor代码。
本文用ID (Identifier的缩写)来代表数据记录的关键字。
数据对象查询一般分为两种:条件查询,返回一个满足条件的数据对象列表; ID查询,返回ID对应的数据对象。
本文主要探讨“条件查询”和“ID查询”这两种情况的缓存策略。
本文只探讨一个JVM内的数据缓存策略,不涉及分布式缓存;本文只探讨对应单表的数据对象的缓存,不涉及关联表对象的情况。

一、Jive的缓存策略
1.Jive的缓存策略的过程描述:
(1)条件查询的时候,Jive用 select id from table_name where …. (只选择ID字段)这样的SQL语句查询数据库,来获得一个ID列表。
(2) Jive根据ID列表中的每个ID,首先查看缓存中是否存在对应ID的数据对象:如果存在,那么直接取出,加入到 结果列表中;如果不存在,那么通过一条select * from table_name where id = {ID value} 这样的SQL查询数据库,取出对应的数据对象,放入到结果列表,并把这个数据对象按照ID放入到缓存中。
(3) ID查询的时候,Jive执行类似第(2)步的过程,先从缓存中查找该ID,查不到,再查询数据库,然后把结果放入到缓存。
(4) 删除、更新、增加数据的时候,同时更新缓存。
2.Jive缓存策略的优点:
(1) ID查询的时候,如果该ID已经存在于缓存中,那么可以直接取出。节省了一条数据库查询。
(2) 当多次条件查询的结果集相交的情况下,交集里面的数据对象不用重复从数据库整个获取,直接从缓存中获取即可。
比如,第一次查询的ID列表为{1, 2},然后根据ID列表的ID从数据库中一个一个取出数据对象,结果集为{a(id = 1),  b(id = 2)}。
下一次查询的ID列表为{2, 3},由于ID = 2的数据对象已经存在于缓存中,那么只要从数据库中取出ID = 3的数据对象即可。
3.Jive缓存策略的缺点:
(1) 在根据条件查找数据对象列表的过程中,DAO的第(1)步用来获得ID列表的那一次数据库查询,是必不可少的。
(2) 如果第(1)步返回的ID列表中有n个ID,在最坏的命中率(缓存中一个对应ID都没有)情况下,Jive还要再查询n次数据库。最坏情况下,共需要n + 1数据库查询。

二、Hibernate的二级缓存策略
Hibernate用Session类包装了数据库连接从打开到关闭的过程。
Session内部维护一个数据对象集合,包括了本Session内选取的、操作的数据对象。这称为Session内部缓存,是Hibernate的第一级最快缓存,属于Hibernate的既定行为,不需要进行配置(也没有办法配置 :-)。
Session的生命期很短,存在于Session内部的第一级最快缓存的生命期当然也很短,命中率自然也很低。当然,这个Session内部缓存的主要作用是保持Session内部数据状态同步。
如果需要跨Session的命中率较高的全局缓存,那么必须对Hibernate进行二级缓存配置。一般来说,同样数据类型(Class)的数据对象,共用一个二级缓存(或其中的同一块)。
1.Hibernate二级缓存策略的过程描述:
(1)条件查询的时候,总是发出一条select * from table_name where …. (选择所有字段)这样的SQL语句查询数据库,一次获得所有的数据对象。
(2) 把获得的所有数据对象根据ID放入到第二级缓存中。
(3) 当Hibernate根据ID访问数据对象的时候,首先从Session一级缓存中查;查不到,如果配置了二级缓存,那么从二级缓存中查;查不到,再查询数据库,把结果按照ID放入到缓存。
(4) 删除、更新、增加数据的时候,同时更新缓存。

2.Hibernate二级缓存策略的优点:
(1) 具有Jive缓存策略同样的第(1)条优点:ID查询的时候,如果该ID已经存在于缓存中,那么可以直接取出。节省了一条数据库查询。
(2) 不具有Jive缓存策略的第(2)条缺点,即hibernate不会有最坏情况下的 n + 1次数据库查询。
3.Hibernate二级缓存策略的缺点:
(1) 同Jive缓存策略的第(1)条缺点一样,条件查询的时候,第(1)步的数据库查询语句是不可少的。而且Hibernate选择所有的字段,比只选择ID字段花费的时间和空间都多。
(2) 不具备Jive缓存策略的第(2)条优点。条件查询的时候,必须把数据库对象从数据库中整个取出,即使该数据库的ID已经存在于缓存中。

三、Hibernate的Query缓存策略
可以看到,Jive缓存和Hibernate的二级缓存策略,都只是针对于ID查询的缓存策略,对于条件查询则毫无作用。(尽管Jive缓存的第(2)个优点,能够避免重复从数据库获取同一个ID对应的数据对象,但select id from …这条数据库查询是每次条件查询都必不可少的)。
为此,Hibernate提供了针对条件查询的Query缓存。
1.Hibernate的Query缓存策略的过程描述:
(1) 条件查询的请求一般都包括如下信息:SQL, SQL需要的参数,记录范围(起始位置rowStart,最大记录个数maxRows),等。
(2) Hibernate首先根据这些信息组成一个Query Key,根据这个Query Key到Query缓存中查找对应的结果列表。如果存在,那么返回这个结果列表;如果不存在,查询数据库,获取结果列表,把整个结果列表根据Query Key放入到Query缓存中。
(3) Query Key中的SQL涉及到一些表名,如果这些表的任何数据发生修改、删除、增加等操作,这些相关的Query Key都要从缓存中清空。
2.Hibernate的Query缓存策略的优点
(1) 条件查询的时候,如果Query Key已经存在于缓存,那么不需要再查询数据库。命中的情况下,一次数据库查询也不需要。
3.Hibernate的Query缓存策略的缺点
(1) 条件查询涉及到的表中,如果有任何一条记录增加、删除、或改变,那么缓存中所有和该表相关的Query Key都会失效。
比如,有这样几组Query Key,它们的SQL里面都包括table1。
SQL = select * from table1 where c1 = ? ….,  parameter = 1, rowStart = 11, maxRows = 20.
SQL = select * from table1 where c1 = ? ….,  parameter = 1, rowStart = 21, maxRows = 20.
SQL = select * from table1 where c1 = ? …..,  parameter = 2, rowStart = 11, maxRows = 20.
SQL = select * from table1 where c1 = ? …..,  parameter = 2, rowStart = 11, maxRows = 20.
SQL = select * from table1 where c2 = ? ….,  parameter = ‘abc’, rowStart = 11, maxRows = 20.

当table1的任何数据对象(任何字段)改变、增加、删除的时候,这些Query Key对应的结果集都不能保证没有发生变化。
很难做到根据数据对象的改动精确判断哪些Query Key对应的结果集受到影响。最简单的实现方法,就是清空所有SQL包含table1的Query Key。

(2) Query缓存中,Query Key对应的是数据对象列表,假如不同的Query Key对应的数据对象列表有交集,那么,交集部分的数据对象就是重复存储的。
比如,Query Key 1对应的数据对象列表为{a(id = 1), b(id = 2)},Query Key 2对应的数据对象列表为{a(id = 1), c(id = 3)},这个a就在两个List同时存在了两份。

4.二级缓存和Query缓存同步的困惑
假如,Query缓存中,一个Query Key对应的结果列表为{a (id = 1) , b (id = 2), c (id = 3)}; 二级缓存里面有也id = 1对应的数据对象a。
这两个数据对象a之间是什么关系?能够保持状态同步吗?
我阅读Hibernate的相关源码,没有发现两个缓存之间的这种同步关系。
或者两者之间毫无关系。就像我上面所说的,只要表数据发生变化,相关的Query Key都要被清空。所以不用考虑同步问题?

四、Lightor的缓存策略
Lightor是我做的Java开源持久层框架。Lightor的意思是,Lightweight O/R。Hibernate,JDO,EJB CMP这些持久层框架,都是Layer。Lightor算不上Layer,而只是一个Helper。这里的O/R意思不是Object/Relational,而是Object/ResultSet的意思。:-)
Lightor的缓存策略,主要参照Hibernate的缓存思路,Lightor的缓存也分为 Query缓存和ID缓存。但其中有一点不同,两者之间并不是毫无联系的,而是相互关联的。
1.Lightor的缓存策略的过程描述:
(1) 条件查询的请求一般都包括如下信息:SQL, 对应SQL的参数,起始记录位置(rowStart),最大记录个数(maxRows),等。
(2) Lightor首先根据这些信息组成一个Query Key,根据这个Query Key到Query缓存中查找对应的结果ID列表。注意,这里获取的是ID列表。
如果结果ID列表存在于Query缓存,那么根据这个ID列表的每个ID,到ID缓存中取对应的数据对象。如果所有ID对应的数据对象都找到,那个返回这个数据对象结果列表。注意,这里获取的是整个数据对象(所有字段)的列表。
如果结果ID列表不存在于Query缓存,或者结果ID列表中的某一个ID不存在于ID缓存,那么,就查询数据库,获取结果列表。然后,把获取的每个数据对象按照ID放入到ID缓存;并组装成一个ID列表,按照Query Key存放到Query缓存中。注意,这里是把ID列表,而不是整个对象列表,放入到Query缓存中。
(3) ID查询的时候,Lightor先从ID缓存中查找该ID,如果不存在,那么查询数据库,把结果放入ID缓存。
(4) Query Key中的SQL涉及到一些表名,如果这些表的任何数据发生修改、删除、增加等操作,这些相关的Query Key都要从缓存中清空。
2.Lightor的缓存策略的优点
(1) Lightor的ID缓存具有Jive缓存,和Hibernate二级ID缓存的优点。ID查询的时候,如果该ID已经存在于缓存中,那么可以直接取出。节省了一条数据库查询。
(2) Lightor的Query缓存具有Hibernate的Query缓存的优点。条件查询的时候,如果Query Key已经存在于缓存,那么不需要再查询数据库。命中的情况下,一次数据库查询也不需要。
(3) Lightor的Query缓存中,Query Key对应的是ID列表,而不是数据对象列表,真正的数据对象只存在于ID缓存中。所以,不同的Query Key对应的ID列表如果有交集,ID对应的数据对象也不会在ID缓存中重复存储。
(4) Lightor的缓存也没有Jive缓存的最坏情况n + 1次数据库查询缺点。
3.Lightor的缓存策略的缺点
(1) Lightor的Query缓存具有Hibernate的Query缓存的缺点。条件查询涉及到的表中,如果有任何一条记录增加、删除、或改变,那么缓存中所有和该表相关的Query Key都会失效。
(2) Lightor的ID缓存也具有hibernate的二级ID缓存具有的缺点。条件查询的时候,即使ID已经存在于缓存中,也需要重新把数据对象整个从数据库取出,放入到缓存中。

五、Query Key的效率
Query缓存的Query Key的空间和时间开销比较大。
Query Key里面存放的东西不少,SQL, 参数,范围(起始,个数)。
这里面最大的东西就是SQL。又占地方,又花时间(hashCode, equals)。
Query Key最关键的两个方法是hashCode和equals,重点是SQL的hashCode和equals。

Lightor的做法是,由于Lightor直接使用SQL,不用HQL、OQL之类,所以推荐尽量使用static final String的SQL,能够节省空间和时间,以至于Query Key的效率能够相当于ID Key的效率。
至于Hibernate的QueryKey,有兴趣的读者可以去下载阅读Hibernate的各个版本的源代码,跟踪一下QueryKey的实现优化过程。

六、总结
这里列一个表,综合表示Jive, Hibernate, Lightor的缓存策略的特征。
     N + 1问题 重复ID缓存问题 Query缓存支持
Jive缓存           有 无 不支持
Hibernate缓存 无 有 支持
Lightor缓存 无 有 支持

注:
“重复ID缓存问题”的含义是,每次条件查询,不是只取ID列表,而是取出完整对象(所有字段)的列表。这样,同一个ID对应的数据对象,即使在缓存中已经存在,也可能被重新放入缓存。参见相关缓存的缺点描述。
“重复ID缓存问题”的负面效应到底有多大,就看你的select id from …(只选择ID)比你的 select * from … (选择所有字段)快多少。主要影响因素是,字段的个数,字段值的长度,与数据库服务器之间网络传输速度。
不管怎么说,即使选择所有字段,也只是一次数据库查询。而N + 1问题带来的可能最坏的负面效应(N + 1次数据查询)却是非常大的。
选择缓存策略的时候,应根据这些情况发生的概率和正负面效应进行取舍。

-----  added later

看到Robbin在04年6月的一篇相关文章。

Hibernate Iterator JCS分析
http://www.hibernate.org.cn/71.html

Hibernate Iterator JCS分析 写道


  • 上一条:
    Asp.net Core 1.1 升级后操作mysql出错的解决办法
    下一条:
    ASP.NET操作MySql数据库的实例代码讲解
  • 昵称:

    邮箱:

    0条评论 (评论内容有缓存机制,请悉知!)
    最新最热
    • 分类目录
    • 人生(杂谈)
    • 技术
    • linux
    • Java
    • php
    • 框架(架构)
    • 前端
    • ThinkPHP
    • 数据库
    • 微信(小程序)
    • Laravel
    • Redis
    • Docker
    • Go
    • swoole
    • Windows
    • Python
    • 苹果(mac/ios)
    • 相关文章
    • 分库分表的目的、优缺点及具体实现方式介绍(0个评论)
    • DevDB - 在 VS 代码中直接访问数据库(0个评论)
    • 在ubuntu系统中实现mysql数据存储目录迁移流程步骤(0个评论)
    • 在mysql中使用存储过程批量新增测试数据流程步骤(0个评论)
    • php+mysql数据库批量根据条件快速更新、连表更新sql实现(0个评论)
    • 近期文章
    • 智能合约Solidity学习CryptoZombie第三课:组建僵尸军队(高级Solidity理论)(0个评论)
    • 智能合约Solidity学习CryptoZombie第二课:让你的僵尸猎食(0个评论)
    • 智能合约Solidity学习CryptoZombie第一课:生成一只你的僵尸(0个评论)
    • 在go中实现一个常用的先进先出的缓存淘汰算法示例代码(0个评论)
    • 在go+gin中使用"github.com/skip2/go-qrcode"实现url转二维码功能(0个评论)
    • 在go语言中使用api.geonames.org接口实现根据国际邮政编码获取地址信息功能(1个评论)
    • 在go语言中使用github.com/signintech/gopdf实现生成pdf分页文件功能(0个评论)
    • gmail发邮件报错:534 5.7.9 Application-specific password required...解决方案(0个评论)
    • 欧盟关于强迫劳动的规定的官方举报渠道及官方举报网站(0个评论)
    • 在go语言中使用github.com/signintech/gopdf实现生成pdf文件功能(0个评论)
    • 近期评论
    • 122 在

      学历:一种延缓就业设计,生活需求下的权衡之选中评论 工作几年后,报名考研了,到现在还没认真学习备考,迷茫中。作为一名北漂互联网打工人..
    • 123 在

      Clash for Windows作者删库跑路了,github已404中评论 按理说只要你在国内,所有的流量进出都在监控范围内,不管你怎么隐藏也没用,想搞你分..
    • 原梓番博客 在

      在Laravel框架中使用模型Model分表最简单的方法中评论 好久好久都没看友情链接申请了,今天刚看,已经添加。..
    • 博主 在

      佛跳墙vpn软件不会用?上不了网?佛跳墙vpn常见问题以及解决办法中评论 @1111老铁这个不行了,可以看看近期评论的其他文章..
    • 1111 在

      佛跳墙vpn软件不会用?上不了网?佛跳墙vpn常见问题以及解决办法中评论 网站不能打开,博主百忙中能否发个APP下载链接,佛跳墙或极光..
    • 2017-06
    • 2017-08
    • 2017-09
    • 2017-10
    • 2017-11
    • 2018-01
    • 2018-05
    • 2018-10
    • 2018-11
    • 2020-02
    • 2020-03
    • 2020-04
    • 2020-05
    • 2020-06
    • 2020-07
    • 2020-08
    • 2020-09
    • 2021-02
    • 2021-04
    • 2021-07
    • 2021-08
    • 2021-11
    • 2021-12
    • 2022-02
    • 2022-03
    • 2022-05
    • 2022-06
    • 2022-07
    • 2022-08
    • 2022-09
    • 2022-10
    • 2022-11
    • 2022-12
    • 2023-01
    • 2023-03
    • 2023-04
    • 2023-05
    • 2023-07
    • 2023-08
    • 2023-10
    • 2023-11
    • 2023-12
    • 2024-01
    • 2024-03
    Top

    Copyright·© 2019 侯体宗版权所有· 粤ICP备20027696号 PHP交流群

    侯体宗的博客