熟肉视频地址：
1. 面向日志的存储
上节课我们讲完了面向元组的存储，这节课从面向日志的存储设计开始。
在这里，页中不存储元组数据，只会存储日志记录，即通过日志记录我们插入的数据以及我们如何更新系统中的数据，包括：插入元组的语句日志，删除元组的语句日志，更新元组的语句日志。
这种设计写得很快，因为不用在一个页里寻找并更新单个元组，就是在末尾追加写，这样写起来非常快，对于磁盘 I/O 也很好。
但是对于读取，就很麻烦了。为了读取一条记录，我们要做的就是从后向前扫描这个日志，以便重新创建我们想要查询的元组。
当然我们可以做一些优化，比如我们可以建立一个索引，用来找到应用于每个元组的不同日志记录，这样我们就不需要对所有的日志记录进行完整的扫描。但是这带来了而外的元数据存储消耗。
另一种优化方式就是定期压缩这些日志，基本上只是把所有的日志记录压缩成单个值，过程是：获取页的锁并锁定，然后执行压缩，然后释放锁。让我们更深入地讨论一下压缩是如何进行的：
首先是层级压缩(level compaction)的：从顶层开始是第 0 级，我们有这个按照执行顺序排好序的日志文件，它在不断积累，随着时间积累了所有这些页。我们要做的是做一个周期性的压缩，即当第 0 级有两页被填满的时候，将它们里面的记录做归并排序，并压缩到一个更大的文件中并放到下一级，即第 1 级。之后更多的日志文件会在顶层第 0 级建立，我们只是不断重复这个过程，第 1 级有两页满了的就归并排序压缩成为一个新的放入第 2 级，依次类推。
另一种是全体压缩(universal compaction)的：即没有等级概念，只是合并归并压缩相邻的页文件。
数据格式（Data Representation）
如果我们在页面中有一个单独的元组，我们如何存储它，如何解释存储在里面的数据，以及 DBMS 的其他层如何利用或从元组存储中提取它们需要的数据。
元组本质上就是一个字节序列，DBMS 目录中会包含表的模式信息，通过这个模式信息可以解析出元组中的数据。
元组内的数据属性可以有不同的类型，一般常见的类型包括：
- 整数类型：有不同的大小的整数，在 SQL 标准中是基于它们支持的值范围定义的，一般有 BIGINT/SMALLINT/TINYINT/INTEGER 等等
- 浮点数类型或者小数类型：一种是基于 IEEE-754 标准定义的近似浮点值，还有就是固定小数点的小数，一般有 FLOAT/REAL，以及 NUMERIC/DECIMAL 等等。
- 变长类型：这种数据类型并非固定长度，所以带有头部标识数据长度，之后跟着实际数据，比如 VARCHAR/VARBINARY/TEXT/BLOB
- 时间类型：一般通过计算与 Unix Epoch（1970-01-01 00:00:00 UTC）时间经过的时间长度（单位为毫秒或者秒），保存在一个 32 位或者 64 为的整数类型中存储。
这里最棘手的是浮点小数或者任意精度的小数的处理。
对于小数精度不确认的小数，例如不限制计算结果的数字的小数位数这种情况，由于精度是不确认的，所以很难通过一些计算机结构表示出来，例如 C/C++ 中对应的 FLOAT 和 DOUBLE/REAL 等类型，他们是通过 IEEE-754 标准去近似逼近实际存储的小数：
- 最高位 bit 表示符号位（0x8000000000000000）
- 第二到第十二的 bit 表示指数（0x7ff0000000000000）
- 剩下的 bit 表示浮点数真正的数字（0x000fffffffffffffL）
举个例子，78.5 这个数字，对于 double，实际存储的就是：40 53 a0 00 00 00 00 00，转换成二进制：01000000 01010011 10100000 00000000 00000000 00000000 00000000 00000000，符号位：0，指数位10000000101 = 1029，减去阶数 1023 = 实际指数 6，小数部分0.0011101000000000000000000000000000000000000000000000，转换为十进制为0.125 + 0.0625 + 0.03125 + 0.0078125 = 0.2265625， 加上隐含数字 1 为 1.2265625， 之后乘以 2 的 6 次方就是 1.2265625 * 64 = 78.5
double 使用的位数比较多，所以逼近的误差更小一些，float 使用的位数比较少，可能的误差就会大一些。
这里使用一个指定精度显示的程序展示了这种 IEEE-754 标准逼近带来的可能的误差。
如果你是在不需要那么精确的场景，那么可以使用这种 IEEE-754 标准逼近的近似小数，如果你需要很精确的场景，那么就不要用这种了。你就需要使用固定精度的数字类型（Numeric Type）
可以在给数字类型设置一个任意的精度和位数，这些东西在实际系统中如何工作有很多不同的实现。一般来说，商业版的数据库要复杂得多，因为他们知道商业应用对固定精度的数值有很大的需求。但是这里需要权衡，因为你需要的精确度越高会在你的处理过程中需要更多的开销。
postgres 是这样实现其数字数据类型：
这个结构体包括：
int ndigits: 包含数字的个数int weight：第一个数字的权重，实际的数字由第一个数字乘以这个权重组成int scale：放大系数int sign：符号，是正是负还是空NumericDigit *digits：是一个字符数组，保存所有的数字
MySQL 的存储结构也是类似的：
这个结构体包括：
int intg: 小数点前的数字个数int frac：小数点后面的数字个数int len：数字占用字节长度bool sign：符号，是正是负decimal_digit_t *buf：是一个 int32 数组，保存所有的数字
大多数系统不允许元组超过单个页的大小，所以它要么受列的大小限制要么受列的个数限制，或者两者都受限制，所以基本不能指定一个大于一页大小的元组。但是如果元组的某个值大于一页大小怎么办？例如一个某个元组有个值是 VARCHAR 类型，保存了很长的字符串，那么我们不会把所有数据和元组其他数据放在一起，而是把它存储在溢出页中。
