近日，在第14届中国数据库技术大会（DTCC2023）的GaussDB“五高两易”核心技术，给世界一个更优选择专场，华为数据库技术专家李士福详细解读了GaussDB性能调优的相关技术和应用实践。
本篇为大家分享GaussDB性能调优的实践。主要包括三个部分，分别是性能调优的整体介绍，性能调优的关键技术，性能调优的应用实践。
GaussDB性能调优简介
我们知道数据库作为系统软件，在整个计算机体系中起到关键的承上启下作用。可以看到应用程序通过北向接口与数据库进行交互，数据库通过南向接口与操作系统和硬件进行交互。对于数据库系统的性能影响是多方面的，不管是硬件规格、操作系统配置、数据库系统的设计、应用和客户端的连接方式，都会对业务最终的性能表现产生很大的影响，所以数据库的性能表现本质上是整体计算机系统软硬件协调的结果。
数据库性能优化充满复杂性和挑战性，既有主观的成分，也有复杂的一面。性能问题的主观性，举例来说，某个查询消耗是1s，它的性能是好还是坏，是否脱离业务目标很难讲清楚。所以描述性能问题时要目标清晰、描述具体、结果可度量。例如一个问题出现后，需要给出硬件配置、参数信息、部署形态、业务场景、当前结果、期望目标等信息。另一个面临的性能问题是复杂性，通过一个问题表象，很难一眼判断是哪个模块引起的，需要分析出一个明确的方向，进一步观察作业在不同模块间数据流动，用全局视角来分析问题；如果性能问题不是单点的问题，我们需要从中找到引起问题的主要矛盾，然后先解决掉大头，看看是否满足业务诉求。
在遇到数据库性能相关问题时，经常会出现一些行业术语。比如：IOPS通常指数据库系统数据盘每秒读写IO的次数，反映了磁盘IO的读写能力；吞吐量，往往指的是数据库每秒处理事务数TPS或者查询数QPS，反映整体的负载状况；响应时间，指的是数据库中一条查询从发起到结果返回的时间开销，用来识别慢SQL；饱和度，指大并发场景下属于工作队列的任务数，反映当前系统作业被积压的情况，以及忙闲程度。
GaussDB数据库的逻辑架构
分析GaussDB性能问题前，先简单介绍一下其逻辑架构，主要包括以下组件：
-
CM集群管理组件，负责集群、节点、实例级别启停，以及集群状态查询、选主、主备切换等；
-
OM运维管理组件，负责日常的运维和管理操作，例如安装、升级、节点替换等；
-
GTM全局事务管理器，负责生产和维护全局事务ID、快照、sequence等全局唯一信息，确保全局事务一致性；
-
CN协调节点，负责接收应用的访问请求，并将结果返回给客户端；在CN中完成SQL解析和优化后，将计划下发到各DN执行；
-
DN数据节点，负责存储业务数据，执行数据查询业务，并返回执行结果；
-
ETCD一致性组件，存储集群的拓扑状态和信息、主备状态信息、全局事务ID、sequence依赖ETCD、CMS自身仲裁和CMS对数据库组件的仲裁依赖ETCD等。后续ETCD将改为自研组件DCC分布式配置中心来存储集群配置信息，这里面影响业务查询的核心组件是GTM、CN和DN组件。
GaussDB数据库的查询处理流程
了解GaussDB架构后，我们简单梳理一下查询处理流程，拆解到每个模块，展开一下每个模块的功能和性能关注点。
-
查询解析模块，将SQL文本翻译为解析树，这里面性能主要因素是词法、语法、语义分析效率，用到的技术是模板查询免解析和PBE模式绑定变量方式执行。
-
查询优化将进行逻辑优化和物理优化，最终生成物理计划，性能核心点是高效计划生成，包括计划缓存、重写规则、基数估计、代价估计准确率等。
-
在查询执行阶段，执行查询计划，并将结果返回。这里面性能核心点包括SMP并行执行、分布式执行、基于编译技术的算子执行、表达式计算等。
-
在查询时进行数据读取，性能涉及存储引擎的多个模块，包括高效的存储数据、并发控制、事务能力等。最终所有各阶段的执行消耗综合，决定了查询端到端性能。
GaussDB性能调优关键技术
下面介绍一下GaussDB在性能优化方面的几个关键技术。
1. 计划缓存
计划缓存技术，一般在OLTP的业务负载中，因为涉及的数据量较少，通过索引加速数据访问路径后，查询解析、重写、优化占比就很高。对于模板行的语句，可以将模板语句的计划缓存起来，那么同模板不同参数语句执行时，可以直接使用缓存计划，大大提升并发吞吐量。我们设想一下，缓存计划是针对一个session，还是针对整个系统的，由此引申出两个概念，local plan cache和global plan cache。如果只在session上缓存已执行计划，可能会导致每个session上执行计划都很多，占用内存资源较高，GPC可以很好解决内存占用问题，但维护代价较大，管理成本高。还有一个问题是，缓存计划可能针对某一类SQL，如果参数变化后，执行计划不优怎么办。GaussDB实现了计划自适应选择的能力，可以自动为不同参数配置最佳的缓存计划。
2. 智能基数估计
智能基数估计主要解决两个问题：一是什么时候创建多列统计信息？二是创建什么类型的统计模型？当前常见的方案是采用MCV（一种软件架构模式）和直方图的统计模型来实现。但这两个方案在单列场景估计的比较准确，在多列场景中仅支持单表，而且误差较大，无法应用。GaussDB创新性地设计出基于库内轻量级贝叶斯网络算子模型来实现多列场景下的基数估计；基于DB4AI的轻量级算子，在数据库内完成训练和推理，对内核几乎无影响；在自动analyze收集统计信息时，自动创建贝叶斯网络模型；优化器在进行多列基数估计时，调用训练好的模型，给出准确率的数值。
3. 分布式查询执行
GaussDB分布式数据库在查询执行过程中，采用多种技术提升查询执行的性能。其中分布式执行框架用于实现分布式集群的多节点并行处理能力，提升集群整体的性能。在复杂语句查询时，会将重执行算子下推到DN节点执行，例如AGG算子等。在下推算子执行时，会考虑数据本地性，尽可能在本地计算，减少数据在网络中的传输开销，从而提升数据库整体的查询性能。在单节点内，通过SMP并行技术，利用多核CPU的并行加速，结合内存管控，提升单节点的性能。
4. GTM Lite
GTM负责全局事务的一致性。传统的GTM组件需要维护每一个活跃事务信息，作业执行时，需要从GTM获取快照时，拿到的是当前的活跃事务链表，如果量特别大，将对网络并发带来压力。GaussDB实现GTM lite能力，通过CSN号代替事务链表，获取的快照仅为CSN号，在事务提交时，也只需要原子加CSN号。在可见性判断时，基于CSN号进行，如果事物结束的CSN比快照中CSN值小，那么元组可见，否则元组不可见。
5. 日志并行流水线
数据库日志系统非常关键，是数据持久化的关键保证。因为日志有顺序依赖关系，所以传统数据库一般采用串行刷日志的设计。GaussDB采用log writer日志写盘线程并行写机制，充分发挥多通道IO的能力。GaussDB日志并行流水线主要机制是将一把大锁，拆分为多个并行的小锁，部分worker线程的事务日志写到一个事务日志共享缓冲区，每个事务结束前保证对应的事务日志LSN已经刷盘，有全局LSN原子加保证顺序。
6. NUMA Aware
GaussDB在多核ARM架构下，通过NUMA Aware技术解决跨NUMA内存访问延迟问题。我们主要做了以下动作：全局数据结构NUMA化改造，关键数据结构包括CLOG、Wal insertlock、proc array等，降低了数据访问延迟；将内核工作线程与NUMA Node进行绑定，避免跨NUMA调度；利用原子操作指令集LSE，提升计算性能。
GaussDB性能调优应用实践
最后介绍性能调优的应用实践。先看看性能调优的思路，遇到性能问题，先确定性能调优的范围，观察是否是某个系统资源达到瓶颈，或者是否存在SQL阻塞或慢SQL。如果是系统资源类问题，通过系统调优来进行诊断和优化；如果是SQL层面问题，通过SQL调优进行诊断和优化，最终看优化后效果是否满足业务需求，如果一次优化不能达成预期，则需要多轮迭代，最终达成目标。
数据库系统整体性能问题的定位思路，先判断是数据库层面问题还是其他层面问题，其他层面问题是否是节点上其他进程引起的数据库性能下降，或者是操作系统参数配置不当引起的。若是数据库层面问题，需要对数据库占用的系统资源信息、数据库内核资源、主备状况等进行综合分析，最后确认问题根因。
在分析单条SQL语句性能时，可以通过使用视图statement_history或者statement，查询语句每个阶段执行的时间消耗，确定语句执行的性能瓶颈。statement_history记录了执行时间超过阈值(log_min_duration_statement，默认3 s)的详细SQL信息，包含计划生成时间、执行时间、锁等待时间等信息；statement记录了SQL按照unique_sql_id归一化的执行信息，包括执行次数、总的执行时间、访问数据量、内存使用等信息。然后通过等待事件视图，查询阻塞会话和对象；最后通过执行计划，获取更细粒度的算子执行情况，如是否走索引、走正确的索引、分布式执行算子stream是否涉及广播等。
讲到GaussDB全量SQL和慢SQL，他们包含哪些内容。GaussDB的多维度指标监控采集粒度不同，对系统性能的影响也不同，主要分为三个级别进行采集。
-
L0级别基本不影响业务执行，采集信息包括实例信息、语句信息、元组、缓存、执行时间等；
-
L1级别对系统稍微有影响，但可接受，这也是业务上线默认推荐的配置，主要包括执行计划信息和锁的统计次数；
-
开启L2会对系统带来很大影响，通常用在问题定位，包括细粒度锁信息和等待时间等。
下面介绍两个案例。第一个是应用升级后引起了性能剧烈波动，我们先观察一下实例整体执行的时间，看看在哪一步消耗的比重最高，通过归一化视图观察单个SQL，看每一步的执行消耗，发现是在网络发送部分引起的，我们把应用侧进行替换，应用程序更新后这个问题就解决了。
第二个是集群整体性能劣化。我们先观察CN上线程等待状态，发现有些节点等待次数超高；在异常节点上分析等待事件，发现wal sync等待的时间较高，通过对比正常节点，确认该节点上存在wal sync的问题；最后分析出主备间日志LSN分片差异较大，一直在进行回放，影响系统整体性能。
最后介绍一下GaussDB两个自调优利器，分别是索引推荐和分布键推荐，主要用于提供高效推荐。比如索引推荐，可以帮助用户根据业务负载自动推荐合适的索引组合，识别冗余索引和无效索引；在推荐索引时，同时输出正向提升SQL信息和负向提升SQL信息，帮助用户来决策是否使用推荐的索引。
本篇分享就到这里，谢谢大家。
