Database Storage Part1

1.Storage

我们所关注的DBMS结构是面向磁盘的，数据库的主要存储位置是在非易失性的磁盘上。
在存储等级的最上层，是最靠近CPU的设备。这种设备是最快的，但也是最小和最贵的存储设备。离CPU越远，设备将更大、更慢、更便宜。

易失性存储设备：

• 易失性存储设备的电源一旦被拔掉，数据将丢失。
• 易失性存储支持快速byte-addressable的随机访问。也就是说程序可以访问到设备的任意一个byte并获取到其中的数据。
• 一般我们将这种设备称作memory。

非易失性存储

• 非易失性意味着该设备不需要持续的能量来保持数据。
• block/page addressable。这意味着，程序如果想要读取某数据，程序必须将包含该数据的整个block/page读入到内存。
• 擅长读取大量连续的数据。
• 一般我们将这种设备称作disk

现在又出现了一种新的设备，persistent memory。它可以做到和DRAM一样快，但同时又具有disk一样的持续性。
我们关注的是基于disk的数据库，同时系统无法直接在disk上操作数据，所以DBMS的组件需要负责弄清数据如何在易失性的memory和非易失性的disk之间传输。
我们会更加关注如何隐藏disk带来的高延迟，因为从disk上读取数据实在是太慢了。

2.Disk-Oriented DBMS Overview

数据库在disk上，数据库文件中的数据被组织为多个page，其中第一个page被作为directory page。为了操作这些数据，我们需要将数据先读取到memory当中。这将通过buffer pool来实现，它负责管理在disk与memory之间来回移动数据的操作。DBMS还有一个执行引擎，用于执行查询操作。执行引擎会向buffer pool索取一个特定的page，buffer pool会将该page读取到memory当中，并向执行引擎返回一个指向该page（位于memory当中）的指针。buffer pool会确保当执行引擎在操作该部分memory时，执行引擎所需的page已经位于那个位置。

3.DBMS vs. OS

一个高层次的设计目标就是让DBMS可以支持一个超出memory容量的数据库。从disk读取数据是昂贵的，我们必须小心处理。我们并不想让从disk中获取数据的巨大延迟对系统中的其它操作造成影响。我们希望DBMS可以在等待从disk中读取数据的同时，能够继续处理其它的查询操作。
这种高层次的设计目标，与操作系统中经常提到的虚拟内存十分相似。
一种实现该目标的方法是，使用mmap来将一个文件的内容映射到一个进程的地址空间当中，这将让OS来负责数据在memory与disk之间的移动。不幸的是，如果mmap遇到了缺页异常，这将导致进程阻塞。

• 对于写操作，mmap非常不适合。
• DBMS希望掌控一切，知晓哪些数据在被访问、哪些查询操作正在被执行，这将带来更好的performance。
• 操作系统不是我们的朋友。

4.File Storage

DBMS以文件的形式在disk上存储数据库。有些DBMS会使用层次结构的文件进行存储，有的仅仅使用一个文件。
OS对这些文件的内容一无所知，只有DBMS知道如何解析这些被特殊编码的文件。
DBMS的storage manager负责管理数据库的文件。它使用诸多page来表示文件。它会追踪是哪些数据被读取或写进page，以及这些page中有多少空闲的空间。

5.Database Pages

DBMS会在一个或多个文件上组织数据库，而这些文件都以诸多page的形式保存。page可以保存各种各样的数据（tuples, indexes, etc），但绝大部分的DBMS都不会将不同种类的数据混杂在同一个page中。有些系统要求page中的数据是self-contained的。
每一个page都被给予了一个独特的identifier。如果数据库是基于仅仅一个文件的，则page id将是page中的内容在文件中的偏移量。绝大部分的DBMS都有一个间接层，它将page id映射为文件路径以及偏移量。系统的上层会索取特定id的page，则storage manager会将该page id转换为文件以及偏移量，从而找到该page。
绝大部分的DBMS会使用固定大小的page，因为page不定的系统将带来巨大的工程负担。例如，如果使用大小不定的page，删除一个page后，文件中将形成一个空洞，而该空洞将难以被新的page填充（即外部碎片）。
在DBMS中，存在三种不同概念的page：

• Hardware page (usually 4 KB).
• OS page (4 KB).
• Database page (1-16 KB).

存储设备能够保证一次hardware page大小的原子写入。如果我们的database page比hardware page大，我们就需要额外的机制来保证写入操作的安全性，因为系统可能在写入操作执行的半途中crash。

6.Database Heap

有许多方法可以找到DBMS想要的page的位置，heap file organization便是其中之一。
一个heap file是若干未经排序的page，page中tuple的存储顺序也是随机的。
给定一个page id，通过使用Linked List和Page Directory，DBMS可以在disk上定位想要的page：

• Linked List：headers持有两个指针，一个指向free page链，一个指向data page链。但是，如果系统想获取某一指定page，就必须做一次顺序扫描。
• Page Directory：DBMS维护一个特殊的page，这个page将追踪其它page的位置，以及每个page上还有多少空闲空间。
  
  

7.Page Layout

每个page包含一个header，header中保存了page内容的相关元数据：

• page size
• checksum
• DBMS version
• transaction visibility
• self-containment（Some systems like Oracle require this）

有两种主要的方式来保存page中的数据： (1) slotted-pages and (2) log-structured。
Slotted Pages： Page maps slots to offsets：

• 这是当今DBMS中最常用的方法。
• header中包含了slot的数量，最后使用的slot的位置的偏移量，slot array（追踪了每个tuple的开始位置）。
• 增加一个tuple，slot array向后递增，tuples向前递增。当二者相遇时，该page被视为满。
  

Log-Structured： Instead of storing tuples, the DBMS only stores log record：

• 在文件中存储database被如何修改的记录（insert, update, deletes）。
• 执行读操作时，DBMS需要回溯日志文件并重建tuple。
• 快速的写，龟速的读。
• 适合append-only storage的场景，因为这种场景下DBMS不能go back and update the data。
• 为了避免long read，DBMS利用indexes以跳转至日志中的特定位置。它也可以周期性的进行日志压缩。（如果系统中有一个tuple，并且需要更新它，可以直接插入更新后的tuple而不管之前的旧tuple）。

8.Tuple Layout

tuple本质上其实就是一个字节序列。DBMS负责解析这些字节。
Tuple Header： Contains meta-data about the tuple：

• 用于DBMS同步控制协议的可见性信息（哪些事务修改了或创建了tuple）。
• Bit Map for NULLvalues。
• 注意，此处无需存储有关数据库schema的元数据。

Tuple Data： Actual data for attributes：

• 属性通常以创建的顺序进行存储。
• 绝大部分DBMS不允许超出page大小的tuple。

Unique Identifier：

• 每个tuple都有一个独特的identifier。
• 通常：page id+（offset or slot）。
• 应用程序不能使用这些id来表示任何东西。

Denormalized Tuple Data： 如果两个表相关，DBMS可以pre-join它们，从而这两个表会被存储在同一个page上。这会加快DBMS的读取速度，因为这样的读取只需加载一个page。但是这也会导致update操作更加昂贵，因为每个tuple将会变得更大。