Lecture #5: Storage Models & Compression
本文是对CMU15-445课程第5节笔记的一个粗略总结和翻译。仅供个人(M1kanN)复习使用。
本节课介绍了数据库压缩操作，这个知识点在2019年并没有出现。
1. Database Workloads
OLTP: Online Transaction Processing
-
OLTP work load的特点是快速、短时运行的操作，一次对单个实体进行操作的简单查询，以及重复性的操作。
一个OLTP work load通常会处理更多的写而不是读。 -
一个OLTP work load的例子是亚马逊的店面。用户可以把东西添加到他们的 Manag购物车，他们可以 进行购买，但这些行为只影响他们的账户。
OLAP: Online Analytical Processing
- OLAP work load的特点是长期运行的、复杂的查询，对数据库的很大一部分进行读取。在OLAP工作中，数据库系统正在分析并从OLTP-side收集的现有数据中得出新的数据。
- 一个OLAP工作负载的例子是亚马逊计算匹兹堡在下雨天购买最多的商品。
HTAP: Hybrid Transaction + Analytical Processing
- 最近流行的一种新的work load类型是HTAP，它就像一个组合，试图在同一个数据库上做OLTP和OLAP。 Manag Manag
2. Storage Models
有不同的方式来存储页面中的tuples。目前为止，我们假定采用n-ary存储模式。
Storage Model (NSM)
-
行式存储模型。数据的物理结构和他们的逻辑结构是一样的。磁盘是由一个一个block组成的，因此连续的数据也分在了连续的block里。
这种方法是OLTP work load的理想选择，在这种work load中，请求是大量插入的，而事务往往只操作一个单独的实体。
它是理想的，因为它只需要一次获取就可以得到一个元组的所有的所有属性 -
优点：
- 插入、更新、删除快速 Manag Manag
- 对需要整个tuple的查询有利
-
缺点：
- 不利于扫描表的大部分和/或属性的一个子集。
Decomposition Storage Model (DSM)
-
在DSM中，DBMS将所有tuples的单一属性（列）连续地存储在一个数据块中。
其实是关系表的一种设计方式，即每一行记录都分解成二元关系表，每个二元表对应一个属性加一个ID主键，这样两张表还可以 Join 起来。
因此，它也被称为 "列存储"。这种模式是OLAP工作负载的理想选择，它有许多只读查询，在表的属性子集上进行大量扫描。
-
优点：
- 减少了I/O的浪费，因为DBMS只读取它需要 Manag的数据来进行查询。
- 更好的查询处理和数据压缩
-
缺点：
- 因为tuple之间是spliting和stitching的，所以点查询、插入、更新和删除的速度很慢。
-
在使用列存储时，要把tuple重新组合起来，有两种常见的方法
-
(常用)固定长度的偏移量。
知道一个给定的列中的值将与另一列中相同偏移量的值相匹配，它们将对应于同一个tuple。因此，列内的每一个值都必须是相同的长度。 -
(更不常用)使用嵌入式元组ID。
对于列中的每个属性，DBMS存储一个 Manag元组ID（例如：一个主键）与它。然后，系统还将存储一个映射，告诉它如何跳到具有该ID的每个属性。
请注意，这种方法有很大的存储开销，因为它需要为每个属性条目存储一个元组ID。
-
关于NSM和DSM参考：DSM的优缺点是什么
3. Database Compression
-
压缩操作被在disk-based DBMSs广泛应用。因为disk的I/O总是瓶颈，所以压缩可以让系统提升性能，尤其是只读analyt Managical workloads上。
如果事先对tuples进行了压缩，DBMS可以获取更多有用的tuple，但代价是要付出更大的压缩和解压的计算开销。
-
内存中的DBMS更加复杂，因为它们不必从磁盘中获取数据来执行一个查询。
内存比磁盘快得多，但压缩数据库可以减少DRAM需求和处理。而且必须在速度和压缩率中取得一个平衡。压缩数据库可以减少DRAM的需求和查询执行过程中的CPU成本。
-
如果数据集是完全随机的bits，那么我们没有办法进行压缩。然而，现实世界中的数据集有一些key properties 是可以进行压缩的。
- 数据集往往具有高度倾斜的属性值分布（例如，Brown语料库的Zipfian分布）。
- 数据集往往在同一元组的属性之间有很高的相关性（例如，邮政编码到城市。订单日期与发货日期）。 Manag
-
鉴于此，我们希望一个数据库压缩方案具有以下特性。
- 必须产生固定长度的值。唯一的例外是存储在独立池中的变长数据。这因为DBMS应该遵循单词对齐的原则，并且能够使用偏移量访问数据。
- 允许DBMS在查询执行过程中尽可能地推迟解压 （late materialization）
- 必须是无损方案，因为人们不喜欢丢失数据。任何种类的有损压缩都必须在应用层面上进行
Compression Granularity
在给DBMS增加压缩功能之前，我们需要决定我们要压缩什么样的数据。这个决定决定了压缩方案的可用性。有四个级别的压缩 Manag颗粒度（granularity）
-
Block Level:
压缩同一张表的tuple块。 -
Tuple Level:
压缩整个tuples的内容（仅NSM）。 -
Attribute Level:
在一个tuple内压缩单个属性值。可以针对同一tuple的多个属性。 -
Columnar Level:
为多个tuple存储的一个或多个属性压缩多个值
(只限于DSM)。这允许更复杂的压缩方案。
Manag4. Naive Compression
-
DBMS使用一个通用的算法对数据进行压缩 (e.g., gzip, LZO, LZ4, Snappy, Brotli, Oracle OZIP, Zstd)。 尽管DBMS可以使用几种压缩算法，但工程师们往往选择那些经常提供较低压缩率以换取更快的压缩/解压的算法。
-
naive compression例子： MySQL InnoDB
DBMS对磁盘页面进行压缩，将其压缩到2KB的幂数，并将其存储到缓冲池中。然而，每次DBMS试图读取数据时，缓冲池中的压缩数据必须被解压
-
由于访问数据需要对压缩的数据进行解压，这就限制了压缩方案的范围。
如果目标是将整个表压缩成一个巨大的块，使用naive compression 方案是不可能的，因为每次访问都需要对整个表进行压缩/解压缩。
因此，对于MySQL来说，由于压缩范围有限，它将表分解成更小的块状。 -
另一个问题是，这些naive方案也没有考虑到数据的高级含义或语义。
该算法既不考虑数据的结构，也不考虑查询打算如何访问 数据。因此，这就失去了利用late materialization 的机会，因为DBMS不能知道它何时能够延迟数据的解压。
5. Columnar Compression
Run-Length Encoding
-
参考：[RLE压缩算法详解 ]
RLE算法的原理就是用一个表示块数的属性加上一个数据块代表原来连续的若干块数据，从而达到节省存储空间的目的。
RLE compresses runs of the same value in a single column into triplets: （不太懂这个runs of the same value的意思）
- The value of the attribute
- The start position in the column segment
- The number of elements in the run
-
DBMS应该事先对列进行智能排序，以最大化压缩机会。这就把重复的属性集中起来，从而提高压缩率
Bit-Packing Encoding
- 当一个属性的值总是小于该值所声明的最大尺寸时，将它们存储为较小的数据类型。
Mostly Encoding
- 用Bit-Packing策略时，可RLE算法的原理就是用一个表示块数的属性加上一个数据块代表原来连续的若干块数据，从而达到节省存储空间的目的。以用一个特殊的标记，来表示当数值超过了最大size，然后维持一个look-up表来保存他们。
Bitmap Encoding
-
DBMS为一个特定属性的每个唯一值存储一个单独的位图，其中向量中的偏移量对应于一个tuples。位图中的第i个位置对应于表中的第i个元组，表示该值是否存在。位图通常被分割成几块，以避免分配大块的连续内存。
-
这种方法只有在值的基数(cardinalty)较低时才实用，因为位图的大小与属性值的基数是线性关系。如果值的基数RLE算法的原理就是用一个表示块数的属性加上一个数据块代表原来连续的若干块数据，从而达到节省存储空间的目的。很高，那么位图就会变得比原始数据集大。
Delta Encoding
- 与其存储精确的数值，不如记录同一列中彼此相邻的数值之间的差异。基准值可以在线存储，也可以存储在一个单独的查找表中。我们还可以对存储的deltas（差）使用RLE，以获得更好的压缩率。
Incremental Encoding
- 这是一种delta编码，即记录常见的前缀或后缀及其长度，以便它们不需要重复。这对排序的数据来说效果最好。
Dictionary Compression
- 最常见的数据库压缩方案是字典编码。DBMS用较小的代码取代了数值中的频繁模式最常见的数据库压缩方案是字典编码。DBMS用较小的代码取代了数值中的频繁模式, 然后，它只存储这些代码和一个数据结构（即字典），将这些代码映射到其原始值。一个字典压缩方案需要支持快速编码/解码，以及范围查询。
Encoding and Decoding
- 最后，字典需要决定如何对数据进行编码（将未压缩的值转换成其压缩形式）/解码（将压缩的值转换成其原始形式）。（不可能使用哈希函数）
- 编码后的值也需要支持以与原始值相同的顺序排序。这可以确保在压缩数据上运行的压缩查询返回的结果与在原始数据上运行的未压缩查询一致。这种保序的特性允许直接在编码上进行操作。