【CMU 15-445】04 数据库存储-2

Slides
Notes

1. 数据表示

​ 元组的数据本质上只是字节数组。这取决于DBMS知道如何解释这些字节来派生属性值。数据表示模式是DBMS存储值的字节的方式。

​ 可以存储在元组中的主要类型有四种：整数(integers)、可变精度数字(variable precision numbers)、定点精度数字(fixed point precision numbers)、可变长度值(variable length values)和日期/时间(dates/times)。

整数

• 大多数DBMS使用IEEE-754标准指定的“原生”C/C++类型存储整数。这些值是固定长度。
• 示例：INTEGER、BIGINT、SMALLINT、TINYINT。

可变精度数字

• 使用IEEE-754标准指定的“本机”C/C++类型的不精确、变精度的数值类型。这些值也是固定长度。
• 可变精度数字比arbitrary精度数字计算速度更快，因为CPU可以直接对其执行指令。·例子：FLOAT, REAL。

定点精度数字

• 这些是具有arbitrary精度和小数位数的数值数据类型。它们通常存储在精确的、可变长度的二进制表示中，并带有附加的元数据，这些元数据将告诉系统小数应该在哪里等信息。
• 在舍入误差不可接受的情况下使用这些数据类型，但DBMS会为获得这种精度而付出性能代价。·示例：NUMERIC, DECIMAL。

可变长度数据：

• 任意长度的字节数组
• 有一个header，可以跟踪字符串的长度，以便轻松跳到下一个值。
• 大多数DBMS不允许元组超过单个页面的大小，因此它们通过在溢出页面上写入值并让元组包含对该页面的引用来解决这个问题。
• 有些系统允许您将这些大值存储在外部文件中，然后元组将包含指向该文件的指针。例如，如果我们的数据库存储照片信息，我们可以将照片存储在外部文件中，而不是让它们在DBMS中占用大量空间。这样做的一个缺点是DBMS不能操作该文件的内容。PostgreSQL: TOAST表
• 示例：VARCHAR、VARBINARY、TEXT、BLOB。

日期与时间：

• 通常，这些数字表示为自Unix时代以来的(微/毫秒)秒数。

• 示例：TIME, DATE, TIMESTAMP。

系统目录—System Catalogs：

​ 为了使DBMS能够读取这些值，它维护一个内部目录来告诉它有关数据库的元数据。元数据将包含数据库有哪些表和列，以及它们的类型和值的排序。

​ 大多数DBMS以用于其表的格式将其目录存储在其内部。

2. Workloads

OLTP: On-line Transaction Processing 联机事务处理

• 快速、运行时间短的操作
• 一次对单个实体执行查询
• Write操作多于read操作
• 重复操作
• 通常是人们首先构建的应用程序
• 示例：用户调用Amazon。他们可以向购物车添加东西，也可以购物，但这些操作只会影响他们的账户。
• 倾向考虑行存储模型

OLAP: On-line Analyitical Processing 联机分析处理

• 长时间运行的更复杂的查询
• Reads 数据库的大部分
• 探索性查询
• 从OLTP端收集的数据派生新数据
• 示例：计算这些地理位置在一个月内购买最多的五项商品。
• 倾向考虑列存储模型

3. 存储模型(Storge Models)

​ 在页面中存储元组有不同的方法。到目前为止，我们假设了 n-ary storage model。

N-Ary Storage Model (NSM)

​ DBMS连续存储单个元组的所有属性，因此NSM也称为“行存储”。这种方法非常适合于事务往往只操作单个实体并插入繁重 workloads（我可以理解为：高并发 吗？）的 OLTP Workloads。它是理想的，因为它只需一次提取即可获得单个元组的所有属性。

优点：

• 快速插入、更新和删除 操作。
• 适用于需要整个元组的查询。

缺点：

• 不适用于扫描表的大部分和/或属性子集。这是因为它会获取处理查询不需要的数据，从而污染了缓冲池。

组织NSM数据库有两种不同的方法：

• 堆组织的表 Heap-Organized Tables：元组存储在称为堆的块中，堆不一定定义顺序。
• 按索引组织的表Index-Organized Tables：元组存储在主键索引本身中，但不同于聚类索引。

分解存储模型 Decomposition Storage Model (DSM)

​ DBMS将所有元组的单个属性(列)连续存储在数据块中。也称为“列存储”。此模型非常适合OLAP工作负载workloads，其中只读查询对表属性的子集执行大型扫描。

优点：

• 减少查询执行过程中浪费的工作量，因为DBMS只读取该查询所需的数据。

• 启用更好的压缩，因为同一属性的所有值都是连续存储的。

  缺点：

• 由于元组拆分/缝合，点查询、插入、更新和删除的速度较慢。

要在使用列存储时将元组重新组合在一起，我们可以使用：

• 定长偏移量 Fixed-length offsets：首先假设属性都是定长的。然后，当系统需要特定元组的属性时，它知道如何跳到文件中的那个位置。为了适应可变长度的字段，系统可以填充它们，使它们都具有相同的长度，或者您可以使用一个字典，该字典接受固定大小的整数并将该整数映射到该值。
• 嵌入的元组ID Embedded Tuple Ids：对于列中的每个属性，将元组ID与其一起存储。系统还需要额外的信息来告诉它如何跳到具有该ID的每个属性。总之，这个几乎没啥用了，因为太耗费资源了。

大多数DBMS使用定长偏移量 Fixed-length offsets。

行存储通常更适合于OLTP，而列存储通常更适合于OLAP。