随笔分类
Disk, Buffer, Files(一)
现如今的存储,仍然以磁盘为主,因为其具有良好的经济效益,从读写速度上来看:Rigister > Buffer(L1, L2, L3 Cache) > RAM > SSD > Magetic Disk,经济效益反之
DBMS是有很多 layers构成的(分层组织),层层叠加,上层通过调用 Api形式抽象下层复杂性,透明化底层实现,实现sql的声明式定义.
SQL Client:管理客户端连接,登录权限校验等
Query Parsing & Optimization:解析、检查、优化 SQL语句,db有着不同的优化原则,最终达成的效果是一致的(查询返回的值之类的)
Relation Operator:将优化后的 SQL语句转化为关系运算符(转化成 DBMS能看得懂的语言)
Files and Table Management: 在逻辑文件中奖表和记录组织成一组页面
Buffer Management: 快速检索,给操作者在 RAM操作错觉
Disk Management:将请求的逻辑页转化为物理字节
访问磁盘是比较昂贵的操作,磁盘IO主要去干的两件事:寻道,旋转,前者指的是移动磁盘到指定磁道的耗时,通常也叫寻道时间,平均 2~3ms,后者指的是旋转延迟,即磁片旋转直至磁头在指定扇区,平均 0-4ms
相比之下,将数据移入、移出磁盘表面每 64kb页面大约 0.25ms,由此可见,降低IO成本的关键在于减少寻道以及旋转
Block Level Storage
读写大的连续字节块
按顺序:"Next"磁盘块最快
最大限度地利用每次读写的数据
"摊销"寻道延迟和写入延迟
预测未来行为
缓存经常使用的块
"Pre-Fetch"可能被访问的块
缓冲区中写入顺序块
术语说明:
Block:磁盘读写的基本单位
64KB~128KB是生产实践不错的数字
教科书上通常写的是 4KB
Page:"Block"的同义词
Disk Space Management
DBMS的最底层,管理空间
目的:
将pages映射到磁盘上的位置
将pages从磁盘加载到内存
将pages写回磁盘&确保写入
更高层次调用此层:
读写page
分配/取消分配逻辑页面
实现:
直接与存储设备打交道
不推荐,若不同设备API不同,设备更换时对应驱动如何操作?考虑点很多
自己去实现 File System
DBMS比OS更加了解page进出背后的底层含义
大多数的FS都会去优化磁盘布局,实现顺序的快速访问
DBMS错觉:FS文件是单一的大文件,但其背后是跨越多个磁盘、机器的 FS文件,即抽象化背后的含义.
Files of Pages of Records
-
Table会被存储为逻辑文件
- File由Pages构成
- Page是包含记录的集合
-
Pages管理
- Page被磁盘管理器所管理:向物理磁盘/文件中读写页面
- 在内存中被缓冲区管理器管理:高层面的DBMS会在内存中操作pages
-
DB File
页面的集合,每个页面对应的便是记录的集合
-
高层次的DBMS所用Api
- crud record
- 通过记录id爬取记录数据
- record id可以是一个指针,来定位记录在文件中的位置
- 扫描所有的记录
- 在某些条件下需要去检索的记录
-
跨越多个os文件甚至机器
DB File Structure
Unordered Heap Files
无序堆文件,基本上记录的集合,没有特定的顺序
随着文件的增加/减少,分配页面
为了支持记录级别的操作:
跟踪一个文件中的 pages
跟踪pages中可用空间
跟踪一个page中的 records
实现:
As List:
Header PageId和 Heap FileName存储在其它地方
对于每个page,有两个指针,以及可用空间和数据
这是一种比较糟糕的实现方式,列表意味着寻找可用空间时顺序遍历寻找可用page,比较低效
Better way - Page Directory:(Header pages)
目录中映射pageId以及指针,也会包含page相关元信息
Header Page访问频率很高,通常存储在缓存中
在缓存中找到一个适合记录的 page比 List链接的寻找方式需要更少的页面加载
加载一个 Header page会去显示更多的页面的空闲空间信息
Video3 34:17
Page Layout
页面的布局:slotted page
这块沿用 15-445里头画过的一张图片:
Page Header是 Page的基本构成,主要包含:
记录的数目
Free Space
Maybe a next/last pointer
BitMap、Slot Table
在设计 Page时,一方面需要弄清楚如何去定位记录,以及其它的设计选择:
Record Length:Fixed ? Variable
Find Record By RecordId
RecordId: (Page, Location In Page)
How we crud Records?
Slotted Page核心元素在于 Slot table,用于去定位 record以及 Page中 free space,也有一种有意思的实现,基于 BitMap来去标记 record是否可去替换,以及基于 Lazy Load在满足特定条件下去 Compact Space
针对 Record Field也有想要探讨的话题,对于一个 Record来说,其相同类型的字段是固定长度的,还是可变程度的,这将一定程度影响到记录的格式,对于固定长度的字段,寻找记录中指定字段时,可轻而易举通过算法定位,但一个字段如果类型相同但长度是动态变化的,此时想要定位到此字段有点难度,一种合理的设计是取此字段的最大程度为初始长度,真实长度不够可通过 padding的形式凑齐,另一种方式便如同协议设计般,通过引入新字段来去记录当前字段的真实长度来去实现字段的快速定位,可想而知,此时付出的代价便是空间。
您好,博主
可以投稿服务器或者scdn文章内容吗?
这边可以赞助高防scdn【国内外均可】【一年起】
并且会给您一个心意红包
国内正规持证公司
如果不方便发您的联系方式
以下是我的联系方式!
我的QQ是:2814841448
@a小蓝博客:www.8kiz.cn No need.