这是我参与8月更文挑战的第2天，活动详情查看：8月更文挑战

Data representation

简单的数据类型这里暂未赘述，可以在网上搜索任何相关DBMS的数据类型介绍，或者阅读本节的slide；

large value

对于超过当前page大小的数据，会存储一个指针，指向overflow page专门来存储这个数。

不同的DBMS这个逻辑不一样，有些是大于某个固定值（postgres， 2KB），有些是和page size有关。

BLOB类型会指向一个external file，但是DBMS不能管控一个外部文件中的内容。

system catalogs

用于存储DB的元数据。一般都是存储在自己的 数据库内部。

• table, column, index, view

  • 前文提到过，tuple中不存储schema有关的信息，这部分信息存储在DBMS catalog中，DBMS通过它将tuple（这个本质上的一串字符）解析成对应的属性类型和值。

• user, permission

• 统计数据

  • INFORMATION_SCHEMA是内部的catalog表。

• Show tables, describe one_table 都是在对这个表进行检索（这是仅限于mysql中的语法）

OLAP OLTP

关系型数据模型，并没有规定一条数据的所有属性都必须存放在同一个page中。

事实上，很多时候，为了应对不同的workloads，我们可以有更多样化的存储方式。

Oltp

On-line transaction processing

最常见的业务类型操作，通常是简单的查询或更新，只涉及到少量的数据和实体。

Olap

On-line analytical processing

分析型数据操作，复杂的查询和sql，大规模的数据扫描和读取，涉及到多个表的关联。

Data storage model

不同的存储模型可以更有利于不同的业务需求（oltp or olap）

NSM

N-ary storage model

单一tuple的所有属性都连续的存放在一个page中。也就是常说的行存储（row storage)；

• 优点：快速的增删改，对需要entire tuple的查询很友好
• 缺点：需要扫描的规模太大，也无法灵活的选择只看某个子集

DSM

Decomposition storage model

列存储。将单一属性的数据连续存储在page中。为了识别每个值属于哪条记录，有两种方式：

• Fixed-length offsets，通过计算偏移量来确定序号
• 每一个值都重复记录一次它所属的tuple id

对OLAP类workloads友好。

每一个存储的单元都包括它的tuple id，用来区别这个值是属于哪一个tuple。

• 优点：只需要读取需要的列；有利于查询处理和数据压缩；
• 缺点：单点的增删改查慢，因为每个tuple都被分解了。

总结

前文讲述了数据库中的数据是如何存储、如何维护、如何访问到的，通过前一篇中的知识，我们可以定位到一条具体的数据。那么我们找到的到底是什么呢？

就像任何编程语言一样，数据库中存储的数据也有自己的数据类型，每个表中的每个属性存储的是什么类型的数据，这在建表的时候就是已经确定好了的，所以我们首先了解有多少种数据类型，可以为我们所用。

不同的数据类型会占用不同的长度。每一个table被创建的时候，这些关于这个table的元数据都被存放到数据库的catalog中。如前所述，我们访问数据库、访问表，检索到的目标tuple本质上就是字节序列，为了将其解析成对应的数据和属性，DBMS需要用到这些元数据。

就像我在这个系列的笔记的开篇时就提过的，关系型数据库的数据表，通俗的理解，就是一张二维表格。而根据我们常识对二维表格的理解，它就是一行一行的记录。所以说，按照行来存储看起来是理所应当的（事实上到现在为止，都是按照行存储来描述的，且行存储也是比较常见的存储方式）。但是，随着时代的发展（这句话颇有高考和考研英语作文开头滥竽充数的感觉= =）、应用场景的拓宽，不同类型的数据库应运而生，来应对渐次出现的多种类型工作。我们通常把数据库的workload分为两类，OLTP型和OLAP型。OLTP一般对应业务数据的查询和操作，它的特征是访问的数据量小、逻辑简单，增删改查都涉及，但是要求实时性和满足事务的要求，尤其是涉及到金融方面的数据，对正确性和安全性的要求会尤其高；而OLAP一般对应的是分析型的数据查询，也就是数据分析的相关工作，它的特征是sql语句非常复杂，访问的数据量和涉及到的数据表非常庞大（因为分析往往需要关联表，把很多个实体的若干特征放在一起来分析和操作），但是对实时性要求相对没那么高，并且一般也不会修改表中的数据。

OLAP经常需要用到某个或某些特定的列上的数据，来进行where和join操作。由于OLAP进行的是数据分析，这些分析统计表往往都是非常大的宽表，包含很多列，所以如果仍然用行存储，会显得非常得不偿失（每条数据都要访问全部的列，并且其中绝大多数的列是无用的）。因地制宜，对症下药，于是就有了按列存储的设计。

另外，我最近实习的方向也是olap相关。自己也是刚刚接触这个方向和领域，很多基础知识都还很欠缺，笔记中如有错误，请务必指出~ 所以最近应该会尽快把这个课程学习完，并同步更新这一系列的笔记。有时间的话也会整理一些论文的阅读笔记，如果能给在看的你带来一点点帮助，那真的再好不过了。