上一篇博客提到了数据库管理系统本身的抽象层次, 其中就有 Disk Manager 和 Buffer Pool Manager 作为数据库的存储管理器。
提到”数据库的数据存储方式”时, (尽管有些早)一半涉及到三个层次的存储方式: 文件的存储方式、页面内部的布局、元组的内部布局. 其中为什么需要文件的存储方式与元组的内部布局较好理解, 而数据库中页面的概念将会在下面说明, 为什么数据库需要实现自己的页面.
您可能需要阅读 CSAPP3e第六章(存储器层次结构) | Amiriox’s Storage 来对计算机存储器的层次结构的意义有一定的认识.
为什么需要数据库?
绝大多数学校的程序设计课节课时或开课期间的实验课都会有一个工程实践,
一般是 XX 管理系统,
向刚刚学习程序设计的学生浅显地介绍实际工程中的一些应用(输入输出交互/控制流/数据处理/可持久化),
b 格高一点的如 gitlet
针对可持久化还会有对象的序列化/反序列化等介绍,
建立起对于可持久化数据的基本认知.
一个运行中的程序的实例(进程以及其中可能存在的多个线程)
实质上是一段内存中的数据(代码区/数据区, 堆/栈, 环境和参数),
例如局部变量或者动态分配的内存,
而这些都是不可持久化的数据,
在程序关闭后大部分数据会被操作系统清理.
此时如果想可持久化某些数据使得下次程序启动仍然可以打开,
就需要将数据可持久化到磁盘上(更现代来说是闪存). 例如, 在 XX
管理系统中会通过语言标准库提供的文件输出接口把用户数据或日志逐行存在文件中,
在 gitlet 项目中会把 Commit 的对象等序列化后写入文件.
当然, 这些看似朴素的做法也并不是错误的, 事实上早期的数据库就是这种数据的结构和存储方式耦合度较高的做法(直到关系型数据库的提出), 而直到现在许多数据库(某些 NoSQL)也使用 JSON 等文件格式来表达一个对象的方式来存储数据. 然而, 这样的方式存在许多问题. 其中的主要矛盾是, 现实工程中的数据和数据间关系是复杂的, 而计算机科学中处理复杂问题的最主要手段(可能是唯一的手段)就是抽象.
现代计算机通过每一层都是下一层的缓存的抽象构建出存储器的层次结构, 依据程序的局部性原理巧妙解决了存取信息的速度远小于 CPU 处理速度的问题.
前置知识可看: CSAPP3e第六章(存储器层次结构) | Amiriox’s Storage
Cache lab 分为两个部分:
这是我做起来体感最痛苦的一个, 很多人也有相同的感受. 不过 lab
本身是没什么问题的, CMU 是一款我的问题
禁用大量常见运算符, 强制规定特定位运算运算符和运算符数量限制实现特定运算
所谓 Hacker’s Delight
在写 CSAPP Lab 之前一定要仔细阅读文档, 一行要求都不能落下, 比如这个 lab 就有一些无聊的要求:
0xFF 的)为了您的阅读方便, 本文对于特定位/位模式采用行内引用 (0
或 1, 1000, 1101),
对于数字的十进制值, 位的编号等采用 \(\LaTeX\) 的数字字体 (\(3, 4, 5, 6\))
本文是 OSTEP (Operating System: Three Easy Pieces) 的简单笔记, 由于 OSTEP 和我写博客的叙述思路很像(日常往自己脸上贴金hhh), 所以这里就只列一个大纲供自己复习.
并且本文建立在 一条操作系统的使命 | Amiriox’s Storage 和 CSAPP3e第六章(存储器层次结构) | Amiriox’s Storage 两篇文章的叙述之上, 仅仅增量补充了必要的内容
一些重要的主题 (如调度和并发) 可能 (几乎是一定) 会单独开一篇文章, 在基于这本书介绍的内容下再补充一些我其他地方学到的相关知识和经验.
OSTEP 是一本无论从知识本身还是讲解技巧上都比较不错的书, 推荐读原书而非总结博客.