[15-445]Database Storage2 related memo
Storage 1 主要介绍了 slotted-page 组织数据的情况。但是这种方式会有一些问题比如
1. 页分裂 （比如在一个页上面操作，后续对其进行操作可能会有删除的操作后续可能需要使用 compaction 来合并对应页以释放空间）
2. 无用的 io 消耗。比如说如果我们使用 MySQL 我们要拿单个数据我们最小的查询单位是页，那么我们最少需要读取 16kb 页大小的数据，然后再寻址访问对应数据。
3. 随机的 io 访问，可能会导致我们到处寻找大量不连续的页，但是我们又只需要这些页里面的某些小数据，造成大量随机访问。
Log-Structured Storage
所以为了解决 slotted-page 组织数据的问题，有了高性能插入数据库或者 k-v 数据库经常会使用的数据组织结构 log-structured. 他的特点就是永远往下写，数据 persist 了之后就不会再去修改，当我们需要更新的时候我们会追加一个更新操作，而不是满磁盘找数据页然后读进内存，然后再更新再写回。这样效率就会高非常多，又因为在机械硬盘时代，如果我们一直对一个文件进行追加，我们可以充分受益于顺序读写获得超高的 io 效率。
但是任何东西都是有代价的，当我们不停追加内容的时候，我们终归有一天会写满 files 或者将它写得非常大，所以中间我们需要合并重复的数据或者直接删除不存在的数据来释放空间。
下面这张 slice 说明了这个文件，我们合并 并且有了层级的概念。我们默认不停写且无顺序的是 level0，当我们写的文件大小或者某种条件达到了我们设定的阈值。我们就将老的文件根据 key 合并排序然后变成一个更大的文件进行下一级。
那么这种组织形式不太好的地方是什么呢？
1. 写放大。
2. 合并成本高。
其实早些时候很多数据库使用该数据结构都面临合并成本高的问题，甚至有一些超大规模排序合并会 stop the world 。。。这是最大的问题。
关于写放大说的是，当我们写入一条记录之后，但我们又不再更新它。它依然会在合并的时候被读出来，并且又重新写入到合并后的页中，反复循环直到进入更高的层级。
DataType/DataValue handle and Catelog include
关于大文件的存储以及各数据库针对单页存储数据的一些限制见上面的 slices。
上一节我们介绍了要找到一个对应的数据是要知道 page_id + offset/slot 就能定位到，但是当我们拿到这个数据之后我们还需要知道一些 catalog 我们才能将数据还原回来知道他是什么类型的，长度之类的。
所以我们还需要机制存储这些表的 catalog。
后面说了一些字段类型在各不同数据库中的支持，和 schema 的支持。
后续如果实现需要这些细节，我会再回过头来补充这一篇，可能会理解更深刻一些。
Reference:
https://15445.courses.cs.cmu.edu/fall2022/slides/04-storage2.pdf
