Database Storage Part2

1.Data Representation

tuple中的数据本质上只是字节数组。DBMS知道如何解释这些字节，并将之导出得到属性值。data representation schema就是指DBMS如何存储这些属性值的字节形式。
有五种高级的数据类型可以被存储到tuple当中：整数，可变精度数，定点精度数，长度可变数，日期/时间。

Integers
绝大部分的DBMS使用C/C++中的原生数据类型来存储整数，这种存储方式遵循IEEE-754标准。这些值都是定长的。
例如：INTEGER,BIGINT,SMALLINT,TINYINT。

Variable Precision Numbers
使用基于IEEE-754标准的C/C++原生数据类型的可变精度数，都是不精确的。同样，这样的数都是定长的。
对于可变精度数的操作要快于计算任意精度数，因为CPU可以对可变精度数直接执行指令。但是，这将导致在计算时出现rounding error，因为一些数是无法被硬件精确表示的。
例如：FLOAT,REAL。

Fixed-Point Precision Numbers
这些数值型数据具有任意的精度和尺度。它们就像string一样存储，同时还伴随着额外的元数据，这些元数据告诉系统所存储数据的长度和小数点的位置等信息。
当我们无法接受rounding error时，就应该使用这样的数据类型，但同时DBMS也会付出性能上的代价。
例如：NUMERIC,DECIMAL。

Variable-Length Data
这些数据是具有任意长度的。在存储它们的时候，通常会伴随存储其header，这样就可以很容易的跳转到下一条数据。同时，这些数据也会伴随存储其checksum。
绝大部分DBMS是不允许tuple存储超出page大小的数据的。当这样的情况出现时，tuple中通常存储的是指向一个overflow page的指针，数据就存储在这样的overflow page当中。当然，overflow page中也包含指向其它overflow page的指针，直至拥有足够的空间存储数据。
有些系统会要求我们将这些大型数据存储到外部文件当中，而tuple中将会存储指向相应外部文件的指针。例如，如果数据库正在存储图片信息，DBMS可以将数据存储在外部文件中，从而节约大量DBMS的存储空间。这种操作的缺点之一是，DBMS将无法操纵这些文件的内容，因此也将失去持久性或事务保护。

例如：VARCHAR,VARBINARY,TEXT,BLOB。

Dates and Times
date/time的表示方式多种多样。通常来说，它们通常表示为距离unix epoch的单位时间。
例如：TIME,DATE,TIMESTAMP。

System Catalogs
为了解析tuple中的内容，DBMS通常在内部维护了一张存储了有关数据库的元数据的catalog。这些元数据涵盖了很多信息，系统中有哪些表，系统中有哪些数据库，以及它们相应的类型和数据的存储顺序等。
绝大部分的DBMS就像存储普通的表一样来存储catalog，同时它们也都有自己的机制去获取catalog表。

2.Workloads

对于数据库系统来说，世上有许多不同的workload。workload指的是一个系统通常需要处理的请求的类型。我们现在主要关注的是两种workload类型：联机事务处理(OLTP)与联机分析处理(OLAP)。

OLTP: Online Transaction Processing
在OLTP场景下，我们所面临的通常是快速且短暂的运行操作、一次仅作用于一个实体的简单查询操作和重复性操作。OLTP场景下，我们通常需要处理更多的写操作和读操作。
想象一下我们在淘宝购物，我们添加物品到购物车，修改邮寄地址，付款等，这些操作都只会对我们个人的account数据产生影响，而不会影响到其他人的account数据。

OLAP: Online Analytical Processing
在OLAP场景下，我们所面临的通常是长时间的运行、复杂的查询、涉及数据库中大部分内容的读取等操作。我们会在OLTP中收集到大量的数据，而OLAP将会分析这些数据从而得到新的数据。
想象一下，淘宝在后台拥有大量的用户数据，它可以对这些大量数据进行读取分析，得到每个月在不同地区最受欢迎的5件商品。

HTAP: Hybrid Transaction + Analytical Processing
试图在一个数据库同时拥有OLTP和OLAP两种能力。

3.Storage Models

在page中存储tuple有很多方法。

N-Ary Storage Model (NSM)
在NSM中，DBMS将一个tuple中的所有属性值连续的存储在一个page中，因此NSM又通常被称作行存储。这种存储模型非常适合OLTP，即非常适合插入操作非常多、事务通常只对一个实体进行操作的场景。它非常理想，因为它可以一次性获取到一个tuple中的所有属性。

Advantages:

• 快速插入，更新，删除。
• 适合需要获取整个tuple的查询操作。

Disadvantages:

• 当需要扫描表中的大部分数据时，只需要多个属性中的部分属性时，这种存储模型是非常糟糕的。因为它会将完全不需要的数据读取到buffer pool中，导致了buffer pool空间的浪费。

Decomposition Storage Model (DSM)
在DSM中，DBMS将所有tuple的某一属性（列）连续的存储在一个数据块当中。因此，这种存储模型也通常被称作列存储。这种模型非常适合OLAP。当仅读取表的部分属性的只读操作非常多时，OLAP非常适合。

Advantages:

• 减少了无效操作，因为DBMS只会读取它需要的那些数据。
• 由于同一属性的所有值都连续存储，因此可以实现更好的压缩。

Disadvantages:

• 由于元组拆分/拼接，点查询，插入，更新和删除的速度很慢。

当我们使用列存储时，我们需要将属于同一个tuple的属性对应起来，通常有两种方法来实现该目标：最常用的方法是fixed-length offsets。假设所有的属性都是固定长度的，DBMS就可以计算每个tuple的属性在存储时的偏移量。当系统索取某个tuple的属性时，它就知道如何跳转到相应的位置。为了容纳可变长度字段，系统可以填充字段以使它们都具有相同的长度，也可以使用采用固定大小整数并将其映射到该值的字典。
不太常见的方法是使用嵌入式元组ID。 在这里，对于列中的每个属性，DBMS都将其存储一个元组ID（例如：主键）。 然后，系统还将存储一个映射，以告诉它如何跳转到具有该ID的每个属性。 请注意，此方法有很大的存储开销，因为它需要为每个属性条目存储一个元组ID。