openGauss数据库源码解析 | openGauss简介(六）

1.5  价值特性

openGauss相比其他开源数据库主要有高性能、高扩展、可维护性和高可用等特点。

1.5.1  高性能

1. CBO优化器

openGauss优化器是典型的基于代价的优化（cost-based optimization，简称CBO）。在这种优化器模型下，数据库根据表的元组数、字段宽度、NULL记录比率、唯一值（distinct value）、最常见值（most common value, 简称MCV）等表的特征值以及一定的代价计算模型，计算出每一个执行步骤的不同执行方式的输出元组数和执行代价（cost），进而选出整体执行代价最小/首元组返回代价最小的执行方式进行执行。

CBO优化器能够在众多计划中依据代价选出最高效的执行计划，最大限度地满足客户业务要求。

2. 行列混合存储

openGauss支持行存储和列存储两种存储模型，用户可以根据应用场景，建表的时候选择行存储还是列存储表。

一般情况下，如果表的字段比较多（大宽表），查询中涉及的列不很多的情况下，适合列存储。如果表的字段个数比较少，查询大部分字段，那么选择行存储比较好。

在大宽表、数据量比较大的场景中，查询经常关注某些列，行存储引擎查询性能比较差。例如气象局的场景，单表有200~800个列，查询经常访问10个列，在类似的场景下，向量化执行技术和列存储引擎可以极大地提升性能和减少存储空间。行存储表和列存储表各有优劣，建议根据实际情况选择。

（1） 行存储表。默认创建表的类型。数据按行进行存储，即一行数据紧挨着存储。行存储表支持完整的增、删、改、查。适用于对数据需要经常更新的场景。

（2） 列存储表。数据按列进行存储，即一列所有数据紧挨着存储。单列查询I/O小，比行存储表占用更少的存储空间，适合数据批量插入、更新较少和以查询为主统计分析类的场景。列存储表不适合点查询，INSERT操作插入单条记录性能差。

行存储表和列存储表的选择原则如下。

（1） 更新频繁程度。数据如果频繁更新，选择行存储表。

（2） 插入频繁程度。如果是频繁少量的插入数据，选择行存储表。一次插入大批量数据，选择列存储表。

（3） 表的列数。如果表的列数很多，选择列存储表。

（4） 查询的列数。如果每次查询时，只涉及了表的少数几个列（<50%总列数），选择列存储表。

（5） 压缩率。列存储表比行存储表压缩率高。但高压缩率会消耗更多的CPU资源。

3. 自适应压缩

当前主流数据库通常都会采用数据压缩技术。数据类型不同，适用于它的压缩算法不同。对于相同类型的数据，其数据特征不同，采用不同的压缩算法达到的效果也不相同。自适应压缩正是从数据类型和数据特征出发，采用相应的压缩算法，实现了良好的压缩比、快速的入库性能以及良好的查询性能。

数据入库和频繁的海量数据查询是用户的主要应用场景。在数据入库场景中，自适应压缩可以大幅度地减少数据量，成倍提高I/O操作效率，将数据簇集存储，从而获得快速的入库性能。当用户进行数据查询时，少量的I/O操作和快速的数据解压可以加快数据获取的速率，从而在更短的时间内得到查询结果。例如支持手机号字符串的大整数压缩、支持numeric类型的大整数压缩、支持对压缩算法进行不同压缩水平的调整。

4. 分区

在openGauss系统中，数据分区是将实例内部的数据集按照用户指定的策略做进一步拆分的水平分表，将表按照指定范围划分为多个数据互不重叠的部分。

对于大多数用户使用场景，分区表和普通表相比具有以下优点：

（1） 改善查询性能：对分区对象的查询可以仅搜索自己关心的分区，提高检索效率。

（2） 增强可用性：如果分区表的某个分区出现故障，表在其他分区的数据仍然可用。

（3） 方便维护：如果分区表的某个分区出现故障，需要修复数据，只修复该分区即可。

（4） 均衡I/O：可以把不同的分区映射到不同的磁盘以平衡I/O，改善整个系统性能。

目前openGauss数据库支持的分区表为范围分区表、列表分区表、哈希分区表。

（1） 范围分区表：将数据基于范围映射到每一个分区，这个范围是由创建分区表时指定的分区键决定的。这种分区方式是最为常用的。范围分区功能，即根据表的一列或者多列，将要插入表的记录分为若干个范围（这些范围在不同的分区里没有重叠），然后为每个范围创建一个分区，用来存储相应的数据。

（2） 列表分区表：将数据基于各个分区内包含的键值映射到每一个分区，分区包含的键值在创建分区时指定。列表分区功能，即根据表的一列，将要插入表的记录中出现的键值分为若干个列表（这些列表在不同的分区里没有重叠），然后为每个列表创建一个分区，用来存储相应的数据。

（3） 哈希分区表：将数据通过哈希映射到每一个分区，每一个分区中存储了具有相同哈希值的记录。哈希分区功能，即根据表的一列，通过内部哈希算法将要插入表的记录划分到对应的分区中。

用户在下发CREATE TABLE命令时增加PARTITION参数，即表示针对此表应用数据分区功能。

用户可以在实际使用中根据需要调整建表时的分区键，使每次查询结果尽可能存储在相同或者最少的分区内（称为“分区剪枝”），通过获取连续I/O大幅度提升查询性能。

实际业务中，时间经常被作为查询对象的过滤条件。因此，用户可考虑选择时间列为分区键，键值范围可根据总数据量、一次查询数据量调整。

5. SQL by pass

在典型的OLTP场景中，简单查询占了很大一部分比例，这种查询的特征是只涉及单表和简单表达式的查询。为了加速这类查询，提出了SQL by pass框架：在parse层对这类查询做简单的模式判别后，进入特殊的执行路径里，跳过经典的执行器执行框架，包括算子的初始化与执行、表达式与投影等经典框架，直接重写一套简洁的执行路径，并且直接调用存储接口。这样可以大大加速简单查询的执行速度。

6. 鲲鹏NUMA架构优化

鲲鹏NUMA架构优化图如图1-9所示。

图1-9  鲲鹏NUMA架构优化图 

openGauss架构优化要点如下。

（1） openGauss根据鲲鹏处理器的多核NUMA架构特点，进行针对性一系列NUMA架构相关优化。一方面尽量减少跨核内存访问的时延问题，另一方面充分发挥鲲鹏多核算力优势。所提供的关键技术包括重做日志批量插入、热点数据NUMA分布、CLOG（commit log，事务提交信息日志）分区等，大幅提升OLTP系统的处理性能。

（2） openGauss基于鲲鹏芯片所使用的ARMv8.1架构，利用大规模系统扩展指令集（large system extension，简称LSE）实现高效的原子操作，有效提升CPU利用率，从而提升多线程间同步性能、XLOG写入性能等。

（3） openGauss基于鲲鹏芯片提供的更宽的L3缓存缓存行，针对热点数据访问进行优化，有效提高缓存访问命中率，降低缓存一致性维护开销，大幅提升系统整体的数据访问性能。

1.5.2  高扩展

在OLTP领域中，数据库需要处理大量的客户端连接。因此，高并发场景的处理能力是数据库的重要能力之一。

对于外部连接最简单的处理模式是per-thread-per-connection模式，即来一个用户连接产生一个线程。这个模式的好处是架构上处理简单，但是高并发下，由于线程太多，线程切换和数据库轻量级锁区域的冲突过大导致性能急剧下降，使得系统性能（吞吐量）严重下降，无法满足用户性能的SLA（service-level agreement，服务等级协议）。

因此，需要通过线程池（线程资源池化复用）技术的技术来解决该问题。线程池技术的整体设计思想是线程资源池化、并且在不同连接之间复用。系统在启动之后会根据当前核数或者用户配置启动固定一批数量的工作线程，一个工作线程会服务一到多个连接会话，这样把会话和线程进行了解耦。因为工作线程数是固定的，因此在高并发下不会导致线程的频繁切换，而由数据库层进行会话的调度管理。

1.5.3  高可用

1. 主、备机

为了保证故障的可恢复，需要将数据写多份，设置主备多个副本，通过日志进行数据同步；可以实现在节点故障、停止后重启等情况下，保证故障之前的数据无丢失，以满足ACID特性。openGauss可以支持一主多备模式，备机接收主机发送过来的WAL并进行回访，保证和主机的数据一致；同时在主机发生故障时，备机可以参照升主机制进行升主机操作。备机过多会消耗过量的资源，而备机太少会降低系统的可用性。

主备机之间可以通过switchover操作进行角色切换，主机故障后可以通过failover操作对备机进行升主机操作。

初始化安装或者备份恢复等场景中，需要根据主机重建备机的数据，此时需要Build（构建）功能，将主机的数据和WAL发送到备机。主机故障后重新以备机的角色加入时，也需要Build功能将其数据和日志与新主拉齐。Build包含全量Build和增量Build；全量Build要全部依赖主机数据进行重建，复制的数据量比较大，耗时比较长；而增量Build只复制差异文件，复制的数据量比较小，耗时比较短。一般情况下，优先选择增量Build进行故障恢复；如果增量Build失败，再继续执行全量Build，直至故障恢复。

openGauss除了流复制主备双机外，还支持逻辑复制。在逻辑复制中把主库称为源端库，备库称为目标端数据库。源端数据库根据预先指定好的逻辑解析规则对WAL文件进行解析，把DML操作解析成一定格式的逻辑日志（例如可以解析成标准SQL语句）。源端数据库把逻辑日志发给目标端数据库，目标端数据库收到后进行回放，从而实现数据同步。逻辑复制只有DML操作。逻辑复制可以实现跨版本复制、异构数据库复制、双写数据库复制和表级别复制等。

2. 逻辑备份

openGauss提供逻辑备份能力，可以将用户表的数据以通用的text或者用户自定义格式备份到本地磁盘文件，并在同构/异构数据库中恢复该用户表的数据。

3. 物理备份

openGauss提供物理备份能力，可以将整个实例的数据以数据库内部格式备份到本地磁盘文件中，并在同构数据库中恢复整个实例的数据。

物理备份主要分为全量备份和增量备份，它们的区别如下：全量备份包含备份时刻点上数据库的全量数据，耗时时间长（和数据库数据总量成正比），自身即可恢复出完整的数据库；增量备份只包含从指定时刻点之后的增量修改数据，耗时时间短（和增量数据成正比，和数据总量无关），但是必须要和全量备份数据一起才能恢复出完整的数据库。当前openGauss同时支持全量备份和增量备份。

4.恢复到指定时间点

时间点恢复(Point In Time Recovery，PITR)基本原理是通过“基础热备 + WAL预写日志 + WAL归档日志”进行备份恢复。重放WAL记录的时候可以在任意点停止重放，这样就有一个在任意时间的数据库一致的快照。即可以把数据库恢复到自开始备份以来的任意时刻的状态。openGauss在恢复时可以指定恢复的停止点位置为LSN（log sequence number，日志序列号）、时间、XID（transaction ID，事务ID）以及用户创建的还原点。

1.5.4  可维护性

1. 支持WDR诊断报告

WDR（workload diagnosis report，工作量诊断报告）基于两次不同时间点系统的性能快照数据，生成这两个时间点之间的性能表现报表，用于诊断数据库内核的性能故障。

WDR主要依赖两个组件：

（1） SNAPSHOT（快照）：快照可以配置成按一定时间间隔从内核采集一定量的性能数据，在用户表空间持久化。任何一个SNAPSHOT可以作为一个性能基线，根据其他SNAPSHOT与之比较的结果，可以分析出与基线的性能表现。

（2） WDR Reporter：报表生成工具基于两个SNAPSHOT，分析系统总体性能表现，并能计算出更多项具体的性能指标在这两个时间段之间的变化量，生成SUMMARY和DETAIL两个不同级别的性能数据。

WDR Reporter是长期性能问题最主要的诊断手段。基于SNAPSHOT的性能基线，从多维度做性能分析，能帮助DBA掌握系统负载繁忙程度、各个组件的性能表现、性能瓶颈。SNAPSHOT也是后续性能问题自诊断和自优化建议的重要数据来源。

2. 慢SQL诊断

慢SQL能根据用户提供的执行时间阈值记录所有超过阈值的执行完毕的作业信息。

历史慢SQL提供表和函数两种维度的查询接口，方便用户统计慢SQL指标，对接第三方平台。用户从接口中能查询到作业的执行计划、开始执行时间、结束执行时间、执行查询的语句、行活动、内核时间、CPU时间、执行时间、解析时间、编译时间、查询重写时间、计划生成时间、网络时间、I/O时间、网络开销、锁开销等。所有信息都是脱敏的。

慢SQL提供给用户对于慢SQL诊断所需的详细信息，用户无须通过复现就能离线诊断特定慢SQL的性能问题。 

3. 支持一键式收集诊断信息

提供多种套件用于捕获、收集、分析诊断数据，使问题可以诊断，加速诊断过程。能根据开发和定位人员的需要，从生产环境中将必要的数据库日志、数据库管理日志、堆栈信息等提取出来，定位人员根据获得信息进行问题的定界定位。

一键式收集工具可以根据生产环境中问题的不同，从生产环境中获取不同的信息，从而提高问题定位定界的效率。用户可以通过改写配置文件，收集自己想要的信息：

（1） 通过操作系统命令收集操作系统相关的信息。

（2） 通过查询系统表或者视图获得数据库系统相关的信息。

（3） 数据库系统运行日志和数据库管理相关的日志。

（4） 数据库系统的配置信息。

（5） 数据库相关进程产生的core（内核）文件。

（6） 数据库相关进程的堆栈信息。

（7） 数据库进程产生的trace（跟踪）信息。

（8） 数据库产生的redo（重做）日志文件。

（9） 计划复现信息。