CMU15-445：Lecture #03 笔记

Lecture #03: Database Storage (Part I)

---

本文是对CMU15-445课程第三节笔记的一个粗略总结和翻译。仅供个人(M1kanN)复习使用。

---

1. Storage

• 存储
  我们将关注一个 "面向磁盘 "的DBMS架构，它假定数据库的主要存储位置是在非易失性磁盘上。 越接近CPU，存储就越快，容量越小，也更贵。

  • Volatile Devices （MEMORY）

  • Non-Volatile Devices （DISK）

• 注意：
  这课不讨论NVMe SSD -- non-volatile memory express.

• We will focus on hiding the latency of the disk rather than optimizations with registers and caches since getting data from disk is so slow.

2. Disk-Oriented DBMS Overview

• 数据库都在磁盘上，数据库文件中的数据被组织成页，第一页是目录页。为了对数据进行操作，DBMS需要将数据引入内存。
  • 它通过拥有一个缓冲池来管理数据在磁盘和内存之间的交换
  • DBMS也有一个执行查询的执行引擎。执行引擎将要求缓冲池提供一个特定的页面，而缓冲池将负责把该页面带入内存，并给执行引擎一个指向内存中该页面的指针
    缓冲池管理器将确保在执行引擎对该部分内存进行操作时，该页就在那里。

3. DBMS vs. OS

• DBMS的一个高级设计目标是支持超过可用内存量的数据库。因为访问disk的代价很大，所以使用disk应该要小心。我们不希望从磁盘上访问数据时停顿太久，从而拖慢其他一切。我们希望DBMS能够处理在等待从磁盘获取数据时，能够处理其他查询。

• 这个高层次的设计目标就像虚拟内存一样，有一个大的地址空间和一个供操作系统从磁盘引入页面的地方。

• 实现这种虚拟内存的方法之一是使用mmap来映射进程地址空间中的文件内容，这使得操作系统负责在磁盘和内存之间来回移动页面。
  但不幸的是，如果mmap遇到页面故障，进程将会被阻塞。

  • 如果你需要写入，你永远不想在你的DBMS中使用mmap。
  • DBMS（几乎）总是想自己控制事情，而且可以做得更好，因为它知道更多关于被访问的数据和被处理的查询。
  • 操作系统不是你的朋友。

• 可以通过使用操作系统：

  • madvise: 告诉操作系统你打算何时读某些页面。
  • mlock: 告诉操作系统不要把内存范围换到磁盘上。
  • msync: 告诉操作系统将内存范围刷新到磁盘。

出于正确性和性能的考虑，我们不建议在DBMS中使用mmap。

Even though the system will have functionalities that seem like something the OS can provide, having the DBMS implement these procedures itself gives it better control and performance

4. File Storage

• 在其最基本的形式中，DBMS将数据库存储为磁盘上的文件。有些可能使用文件层次结构，有些则可能使用单个文件
• 操作系统对这些文件的内容一无所知。只有DBMS知道如何解读它们的内容，因为它是以DBMS特有的方式编码的。
• DBMS的存储管理器负责管理数据库的文件。它将文件表示为一个 页的集合。它还跟踪哪些数据被读和写到了页面上，以及这些页面有多少可用空间。这些页面中还有多少可用空间。

5. Database Pages

• DBMS将数据库组织在一个或多个文件中的固定大小的数据块，称为页。页面可以包含不同种类的数据（tuple、indexes等）。

• 大多数系统不会将这些类型混合在一页中。
  有些系统会要求页面是自成一体（self-contained）的，也就是说，阅读每个页面所需的所有信息都在页面本身。读取每一页的所有信息都在页面本身

• 每个页面都有一个独特的标识符identifier

  • 如果数据库是一个单一的文件，那么页面ID可以是文件的偏移量。

  • 大多数DBMS有一个中介层（indirection layer），将页面ID映射到文件路径和偏移量。 系统的上层会要求提供一个特定的页号。然后，存储管理程序将把这个页号变成一个文件和一个偏移量以找到该页。

  • 大多数DBMS使用固定大小的页面，以避免支持可变大小页面所需的工程开销。

    因为，对于可变大小的页面，删除一个页面会在文件中产生一个hole，而DBMS难以用新的页面来填补。

• 页在DBMS的3个概念

  1. Hardware page (usually 4 KB).
  2. OS page (4 KB).
  3. Database page (1-16 KB）

• 存储设备保证写的操作是atomic 原子的。
  这意味着，如果我们的数据库页面比我们的硬件页面大，DBMS将不得不采取额外的措施 以确保数据被安全地写出来。 因为当系统崩溃时，程序可能已经完成了将数据库页面写入磁盘的一部分

6. Database Heap

• 有几种方法可以找到DBMS在磁盘上想要的页面的位置，堆文件组织是其中一种方法
  堆文件是一个无序的页面集合，其中的图元是按照 随机顺序存储。

• DBMS可以通过使用页面的链接列表或页面目录在磁盘上找到一个给定的页面ID

  1. Linked List:
     Header page持有指向自由页列表和数据页列表的指针。然而，如果 DBMS正在寻找一个特定的页面，它必须在数据页列表上进行顺序扫描，直到它找到它要找的页面。

  2. Page Directory:

     DBMS维护特殊的页面，跟踪数据页的位置以及每页的可用空间。

7. Page Layout

• 每个页面都包括一个header，记录关于页面内容的元数据。

  • Page size
  • Checksum
  • DBMS version
  • Transaction visibility
  • Self-containment (Some systems like Oracle require this.)

• 放置数据的一个strawman方法是 追踪DBMS在一个页面中存储了多少个tuples，然后在每次添加新的tuples 的时候追加到最后面。然而，问题出现在当tuples被删除或者是变长 variable-length属性的时候

• 有2个主流方法去在一个page中放置数据：

  1. slotted-page
     页面将slots映射到offsets

     • Most common approach used in DBMSs today.
     • Header keeps track of the number of used slots, the offset of the starting location of the last used slot, and a slot array, which keeps track of the location of the start of each tuple.
     • To add a tuple, the slot array will grow from the beginning to the end, and the data of the tuples will grow from end to the beginning. The page is considered full when the slot array and the tuple data meet

  2. log-structured

     下一课介绍。

8. Tuple Layout

tuples本质上是一个字节序列。DBMS的工作是将这些字节解释为属性类型和值。

• Tuple Header：包含了tuple的元数据

  • DBMS的并发控制协议的可见性信息。关于哪个事务创建/修改了该元组
  • NULL值的位图。
  • 注意，DBMS不需要在这里存储关于数据库模式的元数据。

• Tuple Data：数据的实际属性

  • 属性通常按照你创建表时指定的顺序存储
  • 大多数DBMS不允许一个tuple超过一个页面的大小。

• Unique Identifier

  • 数据库中的每个tuple都被分配一个唯一的标识符
  • 一般是：page_id + (offset or slow)
  • 一个应用程序不能依赖这些ID来表示任何东西

• De-normalized Tuple Data:

  如果两个表是相关的，DBMS可以 "pre-join"它们，所以这些表最终会出现在
  在同一个页面上。这使得读取速度加快，因为DBMS只需要加载一个页面而不是两个
  独立的页面。然而，这使得更新更加昂贵，因为DBMS需要更多的空间给每个
  tuples