GaussDB关键技术原理：高性能（一）

引言

对数据库性能进行优化是令人激动的，无论是对其进行性能需求分析、性能需求设计、性能问题定个位都是富于变化又充满挑战的工作，本章围绕“数据库性能”进行全面系统化的介绍，首先从数据库在现代软件栈中所处的位置出发，介绍数据库系统性能、涉及的人员、所做的事情、分析的视角以及面临的挑战；其次，以GaussDB样板对数据库查询处理的主要流程进行详细介绍，帮助大家理解数据库内部的处理流程，各个模块对整体性能的主要问题，以及相应模块在性能优化方面使用到的主要的技术和手段；最后，详细介绍数据库性能相关的关键技术与模块，本章内容大体分为：

1）性能优化系统概述

2）性能视角理解GaussDB查询处理流程

3）数据库高性能关键技术

4）高斯数据库性能优化总结

1 数据库性能优化系统概述

内容概要：本章不独立于数据库本身，把数据库看成是整个系统软件栈的基础软件层部分，对性能、资源、时延等本质内容进行原理上的说明，把数据库性能优化抽象成为对一般基础软件的研究。

目的：从计算机体系结构的角度对性能分析做理论上的铺垫，能够让读者后续对数据库性能优化的理解深入本质如系统资源、CPU、内存、IO等，能够让读者更加客观、具体的理解数据库性能问题。

1.1 数据库的软件栈视角

在深入数据库性能这个领域之前，我们需要明白数据库作为系统软件，如何把数据库的处理性能、吞吐量发挥到极致，其本质上是对整个计算机体系结构的研究，包含了所有的硬件组件和整个软件栈，同时随着近年新硬件、新技术的出现数据库的优化不断的下沉到OS、网络协议栈、硬件层，可以说包括几乎所有的硬件组件和整个软件栈。凡是处于处理路径的环节都可以对数据库的性能产生影响。

从上图中可以看到，数据库这一原本软件层的概念，从性能优化的视角他是全栈的，上层涉及到应用程序、客户端，下层涉及到硬件、网络协议等，确保各个组件模块之间在时序节奏上匹配是性能优化的是一个核心问题，也是性能优化的难点之一，因此理解数据库性能优化需要具备多个维度的基础知识以及系统性的思考问题方式。

备注：本章不独立于数据库本身，把数据库看成是整个系统软件栈的基础软件层部分，对性能、资源、时延等本质内容进行原理上的说明，把数据库性能优化抽象成为对一般基础软件的研究，从计算机体系结构的角度对性能分析做理论上的铺垫，能够让读者后续对数据库性能优化的理解深入本质如系统资源、CPU、内存、IO等，能够让读者更加客观、具体的理解数据库性能问题。

1.2 系统性工程视角理解性能优化

数据库的性能优化是个系统性工程，它包含从对象建模、部署模型设计、业务流程设计、局部处理优化等多个环节，从软件工程的角度来看，对数据库优化有以下3个关键要素需要明确

关键点1：性能设计需要合理分工，优化系统性能是一项需要多类人员参与合作完成的事务，其中包括：

（1）系统设计师：负责系统的整体设计，包括系统级架构设计分析，为容量规划（capacity planning）、性能规划（performance planning）定义明确的指标，以及对各个子模块的指标分解

（2）应用开发人员：负责具体某一个模块的开发，确保在软件模块在局部的性能指标达成

（3）数据库性能专家：参与系统的整体设计，从数据库容量、性能诉求的角度出发给出数据面的优选部署方案、以及对象模型在库内的实现（索引、数据类型等），同时对模块与数据库的交互进行细节优化达成优化目标

关键点2：性能设计需要流程规范化，性能开发过程包含了以下的事情，建议按照顺序执行：

（1）设置性能目标、建立性能模型

（2）基于已有的硬件条件和数据库本身的能力，给出部署模型建议

（3）对开发代码进行性能分析，整理出数据库处理部分的占比、以及优化任务分解

（4）对数据库的建表语句、数据类型、索引方面结合具体业务查询进行详细设计

（5）系统联调确定当前应用程序与数据库交互效率是否达成性能指标

（6）特定问题的性能分析

（7）重复5/6确定所有的性能问题都已经解决。

因此针对性能设计的建议：

性能设计和开发是贯穿整个系统开发过程的，数据库性能专家在硬件选型、软件设计开发之前，就应当开始工作并持续到系统转维阶段。

性能设计需要有设定明确的性能目标、以及可验证、可度量的性能模型，如果缺失了这一步性能工程工作会被推迟直到问题出现，假设在架构决策确定以后，随着系统开发一步步推进，修复性能问题的难度和成本会越来越大。

1.3 性能复杂并充满挑战

系统的性能工程是一个充满挑战的领域，具体的原因很多，主要的原因在于通常系统性的性能问题有主观的成分也有其复杂的一面，而且常常是多维度问题并存

首先，性能能问题的主观性，通常性能问题按照不同的视角去理解可能会得到不同的结果，例如下面这幅图，不同的人由于其专注点、思考问题的角度不同会得到完全不同的结论

因此关于性能的主观性，可以归纳为以下两点：

软件工程等计算机相关的科学理论知识往往是建立在客观具体范畴上的，大多数业界人士审视问题非黑即白。在进行软件故障查找的时候，只需要判断问题bug是否存在或者是否已修复就可以了。因为问题bug总是伴随着错误信息，而错误信息通常容易解读

性能问题往往是主观的，开始着手性能问题时，对问题是否存在的判断都有可能是模糊的，在性能问题被修复的时候，被一个用户认为是“不好”的性能，另一个可能认为是“好”的。例如：某个查询耗时1s返回，这里是“好性能” 还是“不好的性能呢”？虽然查询响应时间可以用具体的时间单位来准确度量，但如果脱离目标还是很难说明达成的情况或者效果，因此对于性能需要定义清晰的目标

核心重点

性能目标定义要清晰，诸如平均响应时间latency、吞吐量throughput，考虑到波动因素时需要定义的最大响应时间、落进一定响应时间范围内的请求统计其百分比，一定要尽可能的把主观的问题客观化

性能问题描述要具体，需要包含硬件配置、组网、部署模型、测试模型、测试结果的量化描述

举例：

其次，性能问题往往由多个模块交互相互作用而成，造成很难在开始找到实际的根因，更糟糕的时有时甚至会被一些表面的现象带错了方向，导致花费很长时间无法找到实际原因

关于性能问题分析的复杂性主要有以下特征：

特征1：性能问题通常缺少一个明确的分析起点

问题暴露的表象往往只是结果而不是根因，有时候我们只能从猜测开始，比如，

猜测网络时延大

猜测磁盘IO成为了瓶颈

猜测操作系统在调度上不符合我们的预期

猜测某个位置不受控的进程影响了我们

keep in mind：分析性能问题的开始往往需要对这个是不是一个正确的方向做出判断，一个有经验的性能专家往往能够在开始找准方向

特征2：性能问题可能出现在子系统之间复杂的互联上

即便这些子系统隔离时都表现的很好，也可能是由于连锁故障出现的性能问题（模块间交互逻辑不匹配）

Keep in mind：不仅清晰理解模块间数据流、组件之间的关系，还需要理解他们之间是如何协作的，往往需要全局系统的方法

特征3：性能问题可能是多个问题并存

在复杂的系统中可能会有多个问题，他们之间可能相关也可能不相关，因此真正的任务可能不是寻找问题，而是辨别问题或者说辨别哪些问题是重要的

Keep in mind：需要造成当前性能问题的主要矛盾

1.4 性能相关的术语

这里介绍一些在数据库性能调优时经常用到的术语：

（1）关键术语：IOPS（PPS）

每秒钟发生的输入输出操作次数，是数据传输的一个度量方法。对于磁盘的读写，IOPS指的是每秒钟读写次数。数据库场景中，常用IOPS来描述数据库系统数据盘每秒钟对磁盘施加的IO频率，常用PPS来描述网络传输包的频率

（2）关键术语：吞吐量(Throughput)

评价工作执行的速率，在数据传输方面描述的是数据传输的速度（byte/s，bit/s）。在数据库场景中往往指的是每秒钟处理的事务数TPS、查询数QPS

（3）关键术语：响应时间（延时）Response time (Latency)

一次操作完成的时间，包括用于等待和服务的时间，也包括用来返回结果的时间。在数据库场景中用于描述一条查询的从发起到返回结果时的时间开销

（4）关键术语：饱和度Resource Saturation

指的是某一资源无法满足服务的排队工作量。数据库场景中用于描述大并发场景下处于等待工作队列的任务书，通常反映了当前系统作业被积压的情况

（5）关键数据：瓶颈Bottleneck

在系统性能力，瓶颈指的是限制系统性能的那个资源，辨别和优化掉瓶颈是系统性能优化的重要工作

（6）关键术语：工作负载Workload

系统的输入或者是对系统所施加的负载叫做工作负载。对数据库来说，工作负载是用户通过客户端给数据库发送的查询、运维操作等方面的请求

（7）关键术语：缓存Cache

用于复制或者缓冲一定数据的高速存储区域，目的是为了避免关键路径被较慢的处理过程拖慢，从而提高性能。对数据库来说，主要指计划缓存（避免查询重复编译）、结果集缓存物化（避免同类查询重复执行）

以上内容为数据库性能优化系统概述的相关内容，下篇将分享查询处理综述的精彩内容，敬请期待！