没有合适的资源?快使用搜索试试~ 我知道了~
Lec04_存储引擎_下1
需积分: 0 0 下载量 47 浏览量
2022-08-04
12:42:15
上传
评论
收藏 1.73MB PDF 举报
温馨提示
试读
15页
Lec04_存储引擎_下1
资源详情
资源评论
资源推荐
Log-structured的page layout
上⼀篇Blog中介绍的是Tuple-oriented的page layout,接下来介绍Log-structured的page
layout,在这样⼀种数据库⽂件组织⽅式下,tuple中存储的不是数据本⾝,⽽是数据的
log,即数据的变化:
在向数据库中插⼊数据时,会存⼊⼀个tuple,tuple中存储的不是数据本⾝,⽽是
记录了“我插⼊了⼀个什么样的数据”
删除⼀个tuple时,不需要把这个tuple从数据库⽂件⾥除去,⽽是要新增⼀条数
据,新增数据的内容是“我把xxx数据给删了”,也就是说,在删数据时,不是真正
的删去数据,⽽是新加了⼀条log
在修改数据库⽂件的数据时,不是真正的去修改⽂件⾥对应位置的数据,⽽是新写
⼊⼀条log,log记录着“那条数据被我改掉了”
上述这些概念对应的实例如下图右侧所⽰:
在这样的数据库中,我们想要读某个数据的话,就需要从下往上的回放log,因为我们想要
的数据有很⼤的概率是从log的中部及以下的位置第⼀次被插⼊的,如果从上往下回放log,
那么开销太⼤,刚刚说的过程如下所⽰
如果这样还觉得慢的话,可以再做⼀个索引/⽇志,把和id=x有关的操作都汇集起来,存在
某个特定的数据结构⾥,当我们查询的时候直接基于这个特定数据结构的某个实例来回放,
就像下图⼀样
但这种基于log的数据库有⼀个严重的问题,数据库占⽤的存储空间会很庞⼤且冗余(⽐如
说我们对某条数据的频繁修改就会制造很多的log写⼊数据库⽂件,之后对这条数据的每次
查询都要把这些相关的log全都回放⼀遍,效率很低),因此这种数据库⼀般会周期性的压
缩⽇志(⽐如说某个tuple的某个字段先被修改成1,又被修改成2,那么就可以把前⾯那次
修改成1的⽇志删去,因为这样不影响后⾯的任何操作),这种压缩⽇志的思想的实例如下
图所⽰,下图就是上⾯的图的log经压缩后的结果
id为1,2,3的tuple被插⼊时的log都是写在这个page⾥的,因此DBMS可以基于log推断出
它们最终被修改成了什么值,因此只需留下这⼀条信息即可,id=4的tuple被插⼊时的log不
在这个page⾥,因此只能留下⼀个它被删除的log
这种基于log的思路与机制更多的被⽤在KV数据库当中,因为KV数据库是⼀个键对应⼀个
值,不像关系型数据库的⼀个tuple⾥⾯有好⼏个字段,这样的话,KV数据库每次tuple被更
新之后,可以直接基于更新的log来得出K对应的V当前是什么值,反观关系型数据库,某⼀
个字段被更新后,在log回放/压缩时,我们还要查看其他字段的log,检查其他的字段此前
有没有更新,效率⽐KV数据库低的多
压缩⽇志的⽅法也不⽌⼀种,⾸先是层级压缩(Level Compaction),对于像前⾯的例⼦
⾥id为4的tuple,记录它被插⼊和后续更改的log page不是同⼀个page,我们就做不到在单
个的page⾥完成彻底的⽇志压缩,如果我们能同时读取这前⾯提到的这两个page,把它们
⾥⾯关于那条tuple的⽇志整合⼀下,就可以完成最终彻底的压缩,即有关于这个tuple的⽇
志最后只有⼀条,如果两两page合⼆为⼀还是⽆法彻底压缩,那就再度合⼆为⼀,⼀层⼀
层向下合并,有点像Linux的Buddy System,如下图左侧所⽰
Rocks DB也是基于这个原理实现了⽇志的压缩,⽽且它最多能压缩到第七层
剩余14页未读,继续阅读
食色也
- 粉丝: 32
- 资源: 351
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论0