目录
openGauss 数据库 SQL 引擎
openGauss 数据库执行器技术
openGauss 存储技术
一、openGauss 存储概览
二、openGauss 行存储引擎
Ⅰ、行存储引擎总体架构
Ⅱ、行存储的根本模型与页面组织构造
Ⅲ、行存储的多版本治理以及 DML 操作
Ⅳ、基于 CSN 的 MVCC 机制
Ⅴ、行存储的空间回收
Ⅵ、行存储的共享缓存治理
Ⅶ、并行日志零碎设计
Ⅷ、长久化及故障复原零碎设计
三、openGauss 列存储引擎
四、openGauss 内存引擎
openGauss 事务机制
openGauss 数据库安全
openGauss 存储技术
OLTP（联机事务处理零碎）以高并发读写为主，数据实时性要求十分高，数据以行的模式组织，最适宜面向外存设计的行存储引擎。随着内存逐步变大，服务器上万亿字节（TB）大小的内存曾经很常见，内存引擎面向大内存而设计，进步零碎的吞吐量和升高业务时延。OLAP 联机数据分析解决零碎次要面向大数据量剖析场景，对数据存储效率、简单计算效率的要求十分高。列存储引擎能够提供很高的压缩比，同时面向列的计算，CPU 指令高速缓存和数据高速缓存的命中率比拟高，计算性能比拟好，按需读取列数据，大大减少不必要的磁盘读取，非常适合数据分析场景。openGauss 整个零碎设计是可插拔、自组装的，并反对多个存储引擎来满足不同场景的业务诉求，目前反对行存储引擎、列存储引擎和内存引擎。
一.openGauss 存储概览
晚期计算机程序通过文件系统治理数据，到了 20 世纪 60 年代这种形式就开始不能满足数据管理要求了，用户逐步对数据并发写入的完整性、高效的检索提出更高的要求。因为机械磁盘的随机读写性能问题，从 20 世纪 80 年代开始，大多数数据库始终在围绕着缩小随机读写磁盘进行设计。次要思路是把对数据页面的随机写盘转化为对 WAL（Write Ahead Log）的程序写盘，WAL 长久化实现，事务就算提交胜利，数据页面异步将数据刷新到磁盘上。然而随着内存容量变大、保电内存、非易失性内存的倒退，以及 SSD（Solid State Disk，固态硬盘）技术逐步的成熟，IO 性能失去极大进步，经验了几十年倒退的存储引擎须要调整架构来施展 SSD 的性能和充分利用大内存计算的劣势。随着互联网、挪动互联网的倒退，数据量剧增，业务场景多样化，一套固定不变的存储引擎不可能满足所有利用场景的诉求。因而当初的 DBMS 须要设计反对多种存储引擎，依据业务场景来抉择适合的存储模型。
- 数据库存储引擎要解决的问题
数据库存储引擎要解决的问题如下：
(1) 存储的数据必须要保障：原子性（A）、一致性（C）、隔离性（I）、持久性（D）。
(2) 高并发读写，高性能。
(3) 充分发挥硬件的性能，解决数据的高效存储和检索能力。 - openGauss 存储引擎概述
openGauss 整个零碎设计是可插拔、自组装的，反对多个存储引擎来满足不同场景的业务诉求。以后 openGauss 存储引擎有以下 3 种：
(1) 行存储引擎，次要面向 OLTP 场景设计，例如订货、发货、银行交易系统。
(2) 列存储引擎，次要面向 OLAP 场景设计，例如数据统计报表剖析。
(3) 内存引擎，次要面向极致性能场景设计，例如银行风控场景。
创立表的时候能够指定为行存储引擎表、列存引擎表、内存引擎表，反对一个事务里蕴含对三种引擎表的 DML 操作，能够保障事务的 ACID 性质。
二.openGauss 行存储引擎
openGauss 行存储引擎采纳原地更新 (in-place update) 设计，反对 MVCC（Multi-Version Concurrency Control，多版本并发管制），同时反对本地存储和存储、计算拆散部署形式。行存储引擎的特点是反对高并发读写，时延小，适宜 OLTP 交易类业务场景。
行存储引擎总体架构
openGauss 的行存储引擎在设计上反对 MVCC，采纳集中式垃圾版本回收机制，能够提供 OLTP 业务零碎的高并发读写要求，反对存储计算拆散架构、存储层异步回放日志。行存储引擎架构如图 1 所示。
图 1 行存储引擎架构
注：数据页面缓冲池中缓存数据页面，在数据页面外面寄存元组以及元组的历史版本集中管理，应用垃圾清理（Vacuum）线程进行定期的空间回收。
行存储引擎的关键技术有：
(1) 基于事务 ID 以及行号（ctid）的多版本治理。
(2) 基于 CSN（Commit Sequence Number，待提交事务的序列号，它是一个 64 位递增无符号数）的多版本可见性判断以及 MVCC 并发管制机制。
(3) 基于大内存设计的缓冲区治理。
(4) 平滑无性能稳定的增量检查点（checkpoint）。
(5) 基于并行回放的疾速故障实例复原。
次要模块如下（如图 2 所示）：
(1) 存储拜访接口
(2) 索引
(3) 事务管理
(4) 锁治理
(5) 表和分区存储
(6) 页面缓存治理
(7) 表空间治理
(8) Redo 日志治理
(9) 文件拜访接口
图 2 行存储次要模块
行存储的根本模型与页面组织构造
行存储的 Tuple 构造以及页面组织，是行存储 DML 实现、可见性判断以及行存各种性能与管理机制的基石。
因为行存储是基于磁盘的存储引擎，因而在存储格局的设计中听从段页式设计，存储构造须要以页面（page）作为单位，以不便与操作系统内核以及文件系统的接口进行交互。也是因为这个起因，页面的大小须要和指标零碎中一个 block（块）的大小对齐。在比拟通用的 linux 内核中，页面大小默认个别为 8192（8k）。一个根本的 Heap（堆）页面如图 3 所示：
图 3 Heap 页面示意图
页面结尾的地位为整个页面的头部信息，记录了这个页面的公用信息以及一些要害标识。
line_pointer 被搁置与 Header 前面，并向页面尾部扩大。line_pointer 为指向 tuple 理论数据的一个指针，相似于 sentinel（行指针）的作用。
这里须要一提的是，每个 Tuple 在零碎中的惟一标识，ItemPointer，也被称为 CTID，存储的是这一行所在的 block number（即页面号）以及其对应的 line_pointer 的 offset（即这个页面中第几个 line_pointer）。这样由一个零碎内记录的 CTID，能够疾速定位到这个 Tuple 的 line_pointer，也就能够依据 line_pointer 的指针疾速定位到 Tuple 的理论数据。
line_pointer 的必要性也能够比拟容易的总结进去。因为 Tuple 的数据内容自身能够是变长的，因而如果须要找到一个在页面两头的 Tuple，则须要按序遍历页面构造；而 line_pointer 构造自身为定长，因而能够间接以常数的复杂度找到数据所在内存地位。Line_pointer sentinel 的成果也非常显著：line_pointer 的存在使得 Tuple 的对应改变局限于页面外部，而放弃全局标识 CTID 不发生变化；如果没 line_pointer，行更新须要连带更新的元信息、索引以及零碎各处信息的复杂度就显而易见了。
被 line_pointer 指向的行记录自身，则是从页面结尾开始向页面头部延展，这样防止的页面填充过程中可能呈现的数据挪动以及空间节约。
页面头部的 Header 中贮存了如下信息：
(1) Pd_lsn 为最初一次改变此页面事务写下的 WAL（零碎中个别称为 transaction log，简称 xlog）的下一位，被 xlog 机制以及 checkpoint 机制所应用。
(2) Pd_checksum 为页面中的 checksum，为了查看页面的完整性和一致性应用。
(3) Pd_flags 是此页面的标识位，能够让下层对此页面进行解决的接口疾速辨认此页面的一些特色，比方页面是否有空行 / 页面是否写满、页面是否曾经对所有事务全副可见、页面是否被压缩等。
(4) Pd_lower 和 pd_upper 是指向页面闲暇空间起止的指针，即 pd_lower 指向下一个 line_pointer 的地位，而 pd_upper 指向下一个行记录数据填充的地位，这样既能够疾速进行页面的填充批改，也能够不便计算页面的闲暇空间。
(5) Pd_special 指针用于记录一些非凡的存储管理形式以及接口所需的内存区域。
(6) pd_prune_xid 记录上一次对此页面进行清理的 xid。
(7) pd_xid_base 以及 pd_multi_base 为这个页面上 xid 的 base，即该页面上所有的记录的 xid 都由页面本身记录的 xid（32 位）与 base（32 位）计算失去，是 64 位 xid 的实现形式。
每个记录自身（上文 Tuple 的数据局部），则是数据库中最根本的数据存储单位，其本身的构造以及记录的信息也是零碎中存储形式、DML、事务 ACID 的要害。如图 4 所示：
图 4 数据局部构造
(1) Xmin 是最初始的 TransactionID（事务 ID，简称 XID），即插入此条记录的事务 ID。
(2) Xmax 是删除或更新此条记录的 XID。如果此记录未被更改或删除，那么 Xmax 为 0。
(3) T_cid 记录的是 command id，用于一个事务外部多步操作的一种记录与跟踪。
(4) T_ctid 记录了此条记录的 CTID 值，或者是更新版本的 CTID 值。这个会在前面开展 DML 时讲到。
(5) 两个 infomask 是事务以及存储数据状态的标识位，用于疾速判断。
Xmin、xmax 两个事务 ID、联合其 transaction ID（事务 ID）映射的 Clog（提交日志）、CSN Log，一起形成了可见性判断的外围要害因素.
未完待续 …….