一、前言SQL是用于访问和处理数据库的标准计算机语言。GaussDB支持的SQL标准（默认支持SQL2、SQL3和SQL4的主要特性）。本系列将以《云数据库GaussDB—SQL参考》为主线进行介绍。二、GaussDB SQL 中的BOOLEAN表达式介绍1、概念在GaussDB数据库中，BOOLEAN表达式是一种很常见的表达式类型，它用于比较两个条件，来确定其是否为真或假。BOOLEAN表达式可以用于条件判断或在循环语句中作为终止条件。其语法非常简单，只需要使用逻辑运算符对两个条件进行比较。GaussDB SQL支持AND、OR等逻辑运算符，这些运算符可以将结果组合成更复杂的布尔表达式。2、组成运算符：比较运算符（如=、<>、<、>、<=、>=）和逻辑运算符（如AND、OR、NOT等）。操作数：用于比较的字段值或常量。3、语法示例如下截图是游标使用中的SQL部分，SQL中涉及到BOOLEA表达式用于条件判断和循环语句部分，可参考：1）条件判断，见红色方框“v_salary>=20000”，在这个例子中，当v_salary >= 20000 时，则执行THEN 后面的 UPDATE语句。2）循环语句，见蓝色方框“%NOTFOUND”，是游标的属性之一，用于控制程序流程或者了解程序的状态。当最近的DML（数据操作语言）操作（如INSERT，UPDATE，DELETE等）没有影响任何行时，该属性为真。'EXIT WHEN c1%NOTFOUND;' 就会执行。三、在GaussDB SQL中的基础应用使用布尔表达式可以根据特定条件对结果进行过滤，只返回满足条件的数据。以下是一些在SELECT列表中使用布尔表达式的示例。1、示例1，使用比较运算符--根据工资是否大于2w判断其是否为高工资，返回TRUE或FALSESELECT *,(salary > 20000) AS high_salaryFROM company;上述SQL示例中，我们从company表中选择name、age、address、salary和一个布尔表达式(salary > 20000)，该表达式用于判断员工的工资是否高收入。 结果集中的high_salary列将显示布尔值TRUE或FALSE。2、示例2，使用逻辑运算符--根据年龄是否在18-60之间，判断其是否为有效年龄，返回TRUE或FALSESELECT *,(age >= 18 AND age <= 60) AS valid_ageFROM company;上述SQL示例中，我们从company表中选择name、age、address、salary和一个布尔表达式(age >= 18 AND age <= 60)，该表达式用于判断员工的年龄是否有效。 结果集中的valid_age列将显示布尔值TRUE或FALSE。3、示例3，使用IS NOT NULL运算符--判断地址是否为空，返回TRUE或FALSESELECT *,(address IS NOT NULL) AS null_addressFROM company;上述SQL示例中，我们从company表中选择name、age、address、salary和一个布尔表达式(address IS NOT NULL)，该表达式用于判断员工的地址是否为空值。 结果集中的null_address列将显示布尔值TRUE或FALSE。4、示例4，使用like模式匹配操作符LIKE：判断字符串是否能匹配上LIKE后的模式字符串。如果字符串与提供的模式匹配，则LIKE表达式返回为真（NOT LIKE表达式返回假），否则返回为假（NOT LIKE表达式返回真）。--判断地址是否是CN，返回TRUE或FALSESELECT *,(address LIKE 'CN%') AS c_addressFROM company;上述SQL示例中，我们从company表中选择name、age、address、salary和一个布尔表达式(address LIKE 'CN%')，该表达式用于判断员工的地址是否在CN。 结果集中的c_address列将显示布尔值TRUE或FALSE。附：在GaussDB SQL中还有一个模式匹配操作符SIMILAR TO。描述：SIMILAR TO操作符根据自己的模式是否匹配给定串而返回真或者假。他和LIKE非常类似，只不过他使用SQL标准定义的正则表达式理解模式。四、小结BOOLEAN表达式在SQL中非常常用，它们允许开发人员构建逻辑语句，这些语句能够对表中的数据进行复杂的过滤和选择。通过使用布尔表达式，查询结果可以缩小到满足特定条件的行，或者可以根据这些条件对数据进行聚合和分组。总之，布尔表达式可以帮助我们进行逻辑判断和循环控制，提高代码的可读性。 熟练掌握BOOLEAN表达式的使用，在GaussDB SQL等开发过程中非常重要。——结束

引言对数据库性能进行优化是令人激动的，无论是对其进行性能需求分析、性能需求设计、性能问题定个位都是富于变化又充满挑战的工作，本章围绕“数据库性能”进行全面系统化的介绍，首先从数据库在现代软件栈中所处的位置出发，介绍数据库系统性能、涉及的人员、所做的事情、分析的视角以及面临的挑战；其次，以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用于复制或者缓冲一定数据的高速存储区域，目的是为了避免关键路径被较慢的处理过程拖慢，从而提高性能。对数据库来说，主要指计划缓存（避免查询重复编译）、结果集缓存物化（避免同类查询重复执行）以上内容为数据库性能优化系统概述的相关内容，下篇将分享查询处理综述的精彩内容，敬请期待！

求助： openGauss有没有设置sql脚本最大长度的参数？ 类似于PG的statement_max_length，谢谢了！

GaussDB架构介绍（四）从云原生关键技术架构&关键技术方案两方面对GaussDB云原生架构进行了解读，本篇将从关键技术方案的事务存储组件、SQL引擎组件、DCS组件、实时分析组件等方面继续介绍GaussDB云原生架构。事务存储组件云原生数据库支持透明多写，所有节点对等，每个计算节点都可以读写全部的数据页面，事务在本节点执行，没有分布式事务。每个计算节点都有Local buffer pool，采用Remote memory pool扩展计算节点的内存，在多个计算节点之间共享buffer地址，避免页面在多个计算节点之间传来传去。存储引擎采用Inplace update引擎，底层存储接口统一采用段页式存储方式。事务ID本节点分配，保证唯一性。事务提交时间戳统一分配，合并原来的CLOG和CSN LOG统一记录。存储层采用Log is data，把数据库存储引擎的持久化卸载到Page Store执行日志持久化，日志回放修改页面，创建检查点。图1 分布式缓冲池示意图在计算节点，分布式缓冲池位于数据访问层和分布式存储层的中间，所有的数据访问都要经过缓冲池。分布式缓冲池需要保证页面数据的一致性和页面查找访问的高效性，是云原生数据库实现透明多写，内存资源弹性的关键模块。具体设计如下：1、本地内存和远程内存两级缓存本地内存和远程内存的读写时延差别非常大(30~100ns 和 800ns~5us的区别), 哪些页面在本地缓存，哪些页面在远程缓存非常关键。同时还有一个重要的因素需要考虑，那就是页面是否在多个计算节点被读写，因此云原生数据库把页面分为三大类，一类是页面在多个计算节点被读写(Heap页面，FSM页面)，适合存放在远程内存里，页面地址共享；一类是页面大概率被读，几乎不被修改或者极低概率被修改(索引的非叶子页面，系统表的页面)适合存放在本地内存；另外一类是页面只在固定的单节点被读写，(智能路由优化后索引的叶子节点页面)，适合存放在本地内存。理想的页面分布情况如下图所示：图2 理想页面分布示意图2、页面查找机制每个页面缓存对应一个元信息，称为page directory(PD)，它描述了页面的最新版本在哪个节点，也就是page owner node(PON)，页面是否是共享的远程页面地址，以及远程页面地址。PD 也是分布在各个计算节点上，每个计算节点管理一部分PD, 采用一致性Hash的方法管理PD。图3 页面查找示意图索引页面按照Range自动汇聚算法，根据SQL访问把相关页面汇聚到一个节点，提高索引访问的本地内存的亲和性。索引的叶子节点本身就是从左到右按照索引key的大小顺序存放的，因此很容易根据索引的叶子节点自动划分Range，SQL优化器的路由模块按照Range路由就可以让索引页面按照Range汇聚到SQL节点的本地缓存里实现亲和性访问。针对多个索引的多个Range的亲和性场景，优先选择主键作为亲和性的Range路由。3、支持远程内存池, 内存独立扩展。云原生数据库在云上支持各种业务负载，CPU、MEM和Storage的配比很难一开始就配置合适，有的是计算密集型的业务，有的是内存密集型的业务，有的是存储容量大的业务。针对各类业务场景，云原生数据库需要提供精细的各种资源的独立扩展能力。支持远程内存池，实现了集群物理内存独立扩展。内存池是可选服务，也可以跟计算节点合部署。4、本地缓存远程页面地址，页面地址共享，全RDMA/UB单边读写。页面如果频繁在多个节点被读写，为了避免页面在多个节点之间传来传去，采用共享页面地址的方式，SQL节点Local buffer pool里缓存页面的远程地址，通过全单边读写远程页面。在设计上需要考虑读写页面的Latch问题以及写页面过程中故障的处理问题。对于exclusive latch采用lock bit和lock owner node的方式表示，对于share latch，lock bit和lock owner node的方式无法表示， 因为可以有很多发起者同时持有share latch。因此云原生在设计上采用lock-free无锁机制读取页面。5、Lamport LSN在云原生数据库多写的架构下，每个节点有独立的日志流，本地日志流的LSN是本地分配维护的，本地有序逻辑递增，页面在各个SQL节点之间分别被修改的情况下，需要保证在新节点上修改页面产生的日志LSN要比这个页面之前的日志LSN要大才可以，也就是说从多个节点修改过同一个页面，日志虽然在各个节点独立的日志流里，但是要维护修改页面的日志顺序LSN。Redo日志在多个SQL节点都存在，需要保证这些日志的LSN顺序，才可以保证日志回放的顺序正确性，因此采用Lamport LSN。这部分的详细设计请参照文档<< GaussDB Kernel TD V600R001C00 XLog日志系统设计说明书.docx>>。图4 页面Lamport LSN维护示意图SQL引擎组件云原生数据库SQL引擎继承原来openGauss的词法解析，语法解析，查询重写，查询优化和执行引擎的能力。由于云原生数据库是shared disk 架构，一个事务在一个节点上执行，所以不需要原来分布式根据分布式key进行数据分布，分布式执行和分布式2PC提交的能力。为了支持数据库粒度的异地多活，云原生数据库引入了CDB和ADB的概念，SQL引擎在访问表等对象的过程中，需要记录当前执行的数据库上下文信息，内存上下文根据CDB来分配和管理，并且需要把当前的CDB信息透传到存储引擎，把日志持久化到相应CDB的日志流中。云原生支持SQL读写一致性路由，根据当前会话的数据一致性要求和CDB的主备把SQL路由到相应集群进行处理。云原生支持SQL数据亲和性路由，根据数据的访问亲和性对数据进行汇聚，SQL优化识别出数据分区所在节点后，把SQL路由到相应节点进行处理。云原生长期演进要求数据和程序的解耦，在SQL引擎中实现系统表存储和解析的解耦，实现系统表的前向兼容。DCS组件云原生数据库支持DCS一是为了DCS能够支持持久化能力，二是构建一站式的云数据库服务能力。DCS原来是一个share nothing的分布式集群，有自己的通信管理，集群管理和客户端。在云原生数据库中，DCS是作为一个组件集成到整个服务中，主要提供字符串（String）、哈希（Hash）、列表（List）、集合结构（Set、SortedSet）等数据类型的直接存取，包括代理层实现消息收发解析，KV数据的基本读写，数据分片管理和数据存储等功能。通信和集群管理使用云原生的通信和集群管理。图5 DCS方案示意图表1 DCS主要模块模块功能描述代理模块依据GaussDB消息协议实现消息解析、消息封装等功能。代理在DCS服务端集成，不存在实际的代理节点。引入代理的主要目的是屏蔽客户端对服务端实现细节的感知。数据管理实现数据分片分布和管理，保障数据可靠性。通过跳表实现过期删除和对象回收，保障租户内存复用。同时实现双云同步功能。存储模块以分片数据为细粒度实现数据的内存存储、逻辑持久化、多版本备份等能力。云原生DCS服务继承原来DCS内存KV数据的CRUD、路由管理、跨DC复制、逻辑持久化、过期删除、对象回收、数据核查等数据处理功能，需要调整新增的模块功能如下：1、代理层原来DCS客户端协议与Redis兼容，Redis客户端使用RESP（Redis序列化协议）与Redis服务器进行通信，RESP位于TCP之上，客户端和服务器是保持双工的连接。云原生客户端可同时支持SQL操作和KV操作，除了SQL操作的前后端消息协议，还需要考虑KV操作的通信协议。云原生数据库设计目标要求DCS的KV接口完全兼容，但不要求兼容redis原生客户端，所以在不和SQL操作通信协议冲突的前提下，DCS的通信协议继承原来的实现方式，对于冲突的部分，优先保证SQL的通信协议，调整DCS的通信协议实现。2、数据管理数据分片分布基于一致性hash算法，实现分片数据和计算节点的映射。数据分区还是基于经典的一致性hash算法，将(0~2^64-1)的地址空间划分为固定细粒度的分区，主键的hash值会映射到固定的分区中，数据内存存储通过DCS数据管理模块实现。计算节点通过模拟表形式将KV数据存放到存储引擎实现数据落盘。3、DCS在云原生数据库中是shared disk架构，所有节点对等，在DCS初始化时，需要通过一致性hash计算分区管理的owner，在一个节点故障通知一致性视图调整时，需要选择一个节点接管故障节点的分区，并且通过数据库的存储引擎读取数据，恢复内存数据结构。4、DCS提供GR地理复制能力，支持DCS数据进行跨DC数据备份，实现DC故障时业务的无损切换，实现DC容灾。一个源端集群对应多个备份集群，为保证集群能够跨DC通信，通过GR Link建立跨DC的链接，Link代表一个DC到另外一个DC的复制和备份关系的有向链接。用户通过配置好的GR同步备份或复制的规则，才能触发数据同步。LINK、RULE的操作接口在DCS内部实现，规则持久化到系统表或配置表。DC同步跨集群消息转发采用云原生数据库通信系统中跨集群通信服务处理。实时分析组件云原生数据库以OLTP为主，同时也支持基于OLTP数据的OLAP需求，如每日报表。在云原生数据库中，DBA可以选择为这部分表创建列存索引。创建完列存索引之后，执行器在做顺序扫描的时候，会自动选择列存索引进行数据的读取，实现快速扫描计算的能力。云原生数据库以行存为基础，数据的增删改都先以行存的形式落到数据库中。事务、xlog等机制保障了行存的ACID特性。行存采用Inplace-update引擎，一个Tuple一旦被插入到表中，位置基本不会改变。每个Tuple可以用它的物理位置（文件页号+页内偏移，称为RowID），作为唯一标识。事务的多版本在回滚段中，可以根据RowID直接访问。云原生数据库中的列存索引方案如下图所示：列存是根据行存构建的一个read-only的副本，每次对行存的更新操作会在元数据区域（In Memory Delta Unit，IMDU）增加一条RowID记录。列存扫描的时候会查看元数据区域，确定哪些Tuple已经失效，再去行存中根据RowID读相应的数据。后台线程会周期性地更新列存，回收元数据。如果列存索引和更新操作不在同一台机器上，使用batch模式，即把一个事务中产生的所有失效信息，统一打包到一个RPC请求中，发送给列存索引所在的实例上，从而减少对OLTP请求的影响。行存的block为8KB，列存需要较多的数据量才能实现更好的压缩、向量化操作等优化。所以一个IMCU对应多个行存的block，目前暂定为1024个，这样一个1024个block称为一个Super Block。图6 列存索引示意图为了支持列存大小超过内存容量的场景，列存索引支持从内存中置换到磁盘上。但是列存本身在故障情况下并不能保证自身的一致性，故障重启之后列存需要根据行存的内容重新构建。所以这里的磁盘对于列存来说，是内存的延伸，用来缓存额外的数据。因为DU容量小，且经常被修改，所以可以常驻内存。列存索引和行存完全是解耦开的。部署形态上，列存索引既可以与行存在一个实例中，节约物理资源；也可以与行存在不同的实例中，避免OLAP请求对OLTP请求产生影响。两种部署形态分别如下图所示：图7 行存列存混合部署示意图图8 行存列存分开部署示意图PageStore组件PageStore是一个分布式存储，对外提供SAL接口，SQL节点通过SAL接口进行日志和页面的持久化服务，PageStore对象间的映射关系如下图所示。Page Cluster Manager Control Server（集群管理）：页面集群管理控制服务负责整个存储节点的管理，VFS和StoreSpace的管理，以及Slice的分配和调度。VFS：虚拟文件系统，每个租户可以创建一个VFS，集群管理按照VFS统计容量和IO等信息；PG（Placement Group，放置组）：多个存储节点组成一个PG，PG的多个存储节点满足反亲和性。集群管理在分配Slice的时候，按照PG进行分配。Slice：数据存储的基本单元，Slice分配到具体的某个PG，分配到PG后，Slice就运行在PG下的多个节点上。每个Slice管理10G的数据量，10G的数据可能来自多个文件的一段连续页面。Slice逻辑上主要实现SQL节点页面的持久化和快速检索。Slice的元数据采用Btree管理，多个节点的Slice副本通过Raft机制提供数据的可靠性。每个Slice是数据回放的基本单元，实现独立的快照和检查点。Slice存储管理如下图所示。存储节点：每个存储节点上运行一个PageStore进程，PageStore进程会管理多个Slice。PageStore进程内的所有Slice共享BufferPool、ThreadPool、通讯组件、消息分发和PAL等模块功能。多个Slice共享PageStore进程的CPU资源和内存。文件：抽象的存储，为Slice存储数据，Slice会使用多个文件来存储数据。PAL：持久化层，用于对Slice的文件进行持久化，下面可以对接LocalFS、Plog、Lun等。图中红色虚线框为PageStore提供的本地盘持久化方案。图9 PageStore对象关系示意图图10 Slice存储管理示意图备份恢复组件备份和恢复PITR主要是为了应对人为失误、硬件故障和自然灾害等。云原生数据库默认支持一级备份，一级备份是分布式存储Page Store基于append only实现的快照功能，快照数据保存在本集群，用户可以配置开始一级备份的时间段、频率以及保留时间，由OM_Server根据集群的负载等数据生成备份计划。一级备份等于是数据页的备份，为了实现PITR，在开启一级备份后，会默认开启日志归档，通过快照数据+日志实现快速PITR。用户可以设置开启二级备份，一级备份数据保存在本集群，会占用用户生产集群的空间且全闪环境下费用较高，同时为了提高备份数据的可靠性，云原生数据库提供二级备份将备份数据及日志保存在OBS等远端存储上。当一级备份的保留时间过期时，云原生数据库会自动将其转储为二级备份，转储成功后自动删除一级备份的快照。同样用户可以设置二级备份的保留时间，二级备份保留时间过期时会自动将远端存储备份删除。在恢复时，由于云原生数据库一个页面可能涉及多个日志流，需要对多个日志流进行扫描，对日志进行合并恢复。在扫描日志阶段可以根据恢复配置文件配置的恢复点确定恢复的位置，从而在正式恢复时恢复到这个时间点即可。安全云原生数据库是一个分布式系统，各个服务之间，服务与外部应用和外部用户之间，服务与内部应用和内部用户之间主要通过通信进行交互，它们的数据流图如下图所示。图11 安全威胁分析示意图从图中可以看出，云原生主要包括三个通信平面，OM_Monitor，OM_Agent，OM_Server组成的管理平面（操作维护），GaussDB Master Server和DB Cluster Resource Schedule Server组成的控制平面。GaussDB Server，DCS Server，Memory Server，Message Server，Page Server，Page Cluster Manager Control Server组成的用户平面。云原生系统外部交互主要有三类接口：第一类是GaussDB Server，DCS Server提供的业务访问接口，这个接口是外部接口。第二类是OM_Server提供的操作维护接口，这个接口对接公有云的维护后台。第三类是Message Server提供的跨区域集群的消息通信接口，这个接口虽然是内部接口，但通信网络不在内部网络。云原生数据库是一个池化的共享资源系统，不同租户的运行环境通过进程隔离，租户的存储通过VFS进行隔离。为了保证租户数据不泄露，不发生篡改，在控制平面需要对租户身份进行签名认证，租户资源调度信息的传递需要防止仿冒和篡改。在用户平面，不同租户的数据使用不同的秘钥进行加密，对于远程内存操作的RDMA rkey进行随机化，其他安全继承原来数据库的能力，包括用户管理、权限管理和审计。在维护平面，对接入的访问进行认证，对进行的操作进行审计。- END -

 GaussDB架构介绍（三）从智能关键技术方案、驱动接口关键技术方案等方面对GaussDB架构进行了解读，本篇将从云原生关键技术架构&关键技术方案两方面对GaussDB云原生架构展开介绍。  11  GaussDB云原生架构 11.1  云原生关键技术架构  图1 云原生数据库1层逻辑模型  1. 分层原则。整体层次分为三层，分别为Application Layer，Computer Layer和Storage Layer。Application Layer应用层主要是客户端各种语言的驱动，这些驱动通过通信与计算层Computer Layer进行交互，对数据库进行操作。下面是Computer Layer计算层，计算层负责SQL处理和事务处理，数据库的备份处理，集群内和集群间的消息通信，整个集群的管理，与公有云基础服务（认证，计费，运维）的对接。最下面是Storage Layer存储层，存储层负责数据库数据的日志存储，数据存储，数据库的备份存储。  2. 分平面原则。管理面，控制面和用户面。管理面主要包括操作维护子系统，控制面主要包括资源调度子系统，用户面主要包括数据库服务子系统。  3. 适配器原则。底层存储支持本地文件系统，Dorado 存储，Ceph分布式文件系统和DFV存储。这些存储的操作接口统一封装为文件系统接口。  4. 负荷分担。所有子系统的服务节点对等，一个节点故障，其他节点可以接管。  5. 数据存储多副本存储。Dorado 支持多种Raid级别，PLOG存储支持数据存储为3副本。  11.2  关键技术方案 11.2.1 通信组件 云原生数据库采用shared disk架构，各个计算节点对等，计算节点之间通过页面交换实现缓存数据的一致性，为了提高页面传递的效率，需要利用RDMA或UB单边读写的能力；云原生数据库为了管理动态资源，需要对动态资源的owner分配进行加锁，分布式锁管理需要利用原子操作和RPC消息对资源进行加解锁；多租户资源管理服务需要下发调度信息，并从计算节点读取资源状态，需要RPC消息；集群管理组件进行故障检测、发送消息需要使用RPC消息。因此，通信组件需要能够支持原子操作、单边读写、双边RPC和RPC通信。  目前市场上有三种RDMA网络，分别是Infiniband、RoCE(RDMA over Converged Ethernet)、iWARP，如下图所示。其中，Infiniband是专为RDMA设计的网络，从硬件级别保证可靠传输 ，但是成本高昂。而RoCE 和 iWARP都是基于以太网实现的RDMA技术，在目前最广泛使用的以太网上实现了高速、超低延时、极低CPU使用率的RDMA通信。  图2 RDMA网络种类  RoCE协议有RoCEv1和RoCEv2两个版本，RoCEv1是基于以太网链路层实现的RDMA协议(交换机需要支持PFC等流控技术，在物理层保证可靠传输)，允许在同一个广播域下的任意两台主机直接访问；而RoCEv2是以太网TCP/IP协议中UDP层实现，即可以实现路由功能。  表1 InfinieBand和RoCE对比  InfiniBand：设计之初就考虑了 RDMA，从硬件级别保证可靠传输，提供更高的带宽和更低的时延。但是成本高，需要IB网卡和交换机支持。  RoCE：基于Ethernet 做RDMA，消耗的资源比 iWARP 少，支持的特性比 iWARP 多。可以使用普通的以太网交换机，但是需要支持RoCE的网卡。  iWARP：基于TCP的RDMA网络，利用TCP达到可靠传输。相比RoCE，在大型组网的情况下，iWARP的大量TCP连接会占用大量的内存资源，对系统规格要求更高。可以使用普通的以太网交换机，但是需要支持iWARP的网卡。  为了支持各种网卡类型的RDMA协议和实现低时延的网络通信，云原生数据库的节点通信组件的整体架构图如下:   图3 通信组件整体架构图  节点间通信组件包括以下几个模块：RPC接口层、配置管理、通用功能、会话管理，消息处理和协议层。各模块功能描述如下：  表2 模块功能描述  根据对通信时延的计算，一次单边通信留给CPU的时间只有3.36us，为了实现低时延通信，各个模块的设计考虑如下：  1、RPC Interface  根据不同场景对通信接口的需求，RPC接口层提供消息语义、内存语义和原子操作接口，并支持同步、异步和批量调用。  RDMA内存操作需先将内存注册到网卡。论文《用户态RPC over RDMA优化技术的研究与实现》实验表明，传输的块大小越小，内存注册在一次RPC调用中占比越大，当块大小小于64KB时，内存注册开销远大于传输本身的开销。为降低内存注册的开销，通信组件统一申请大块内存并注册到网卡，业务模块需要进行远端内存操作前通过调用请求内存接口获取指定长度的已注册内存。  2、配置管理  配置管理主要是静态设置节点间通信信息，在通信初始化时使用，不在通信关键路径上。  3、通用模块  通用模块主要负责计算节点注册内存的管理和集群间通信消息的转发，在初始化时使用，不在通信关键路径上。  4、会话管理  会话管理主要包括连接管理、上下文管理和传输管理。  RDMA协议通信的基本单元是QP(Queue Pair)，通信的两端都需要创建QP，不同传输模式使用的QP类型不一样，并且支持的RDMA原语也不一样，如下表。  表3 不同传输模式支持的RDMA原语及消息大小  可见，单边读写和原子操作只能使用可靠连接，即每个连接的两个节点需要各自维护一个QP，并且不能被其他目的节点的连接共享。假设有N个节点需要相互通信，则至少需要N * (N - 1)个QP，而QP本身需要占用网卡和内存，当连接数很多时，存储资源消耗将会非常大。经计算一个未经封装的RDMA QP大概占186.67KB (0.1823M) 内存。为降低内存开销，与相同节点通信可以共享QP。但在高并发下竞争QP资源可能成为性能瓶颈。连接分发设计需要考虑性能和资源利用率。连接管理根据QP是否可共享支持共享连接(share-connection)和线程独占连接(per-thread)两种选择。  双边操作可以使用不可靠报文QP，即传输为不可靠数据报文且不同目的节点可共享QP。为节省QP资源，减少过多QP造成网卡cache miss导致的性能下降，考虑双边通信场景选择使用不可靠报文，但是为保证数据的可靠性，需要进一步做可靠性设计。考虑设计滑动窗口实现保序和重传机制，作为后续开发特性。(但是据FaSST测试数据，RDMA的不可靠发送丢包率近乎为0），需要设计传输管理模块实现保序、重传等功能(优先级低))。  由于RDMA协议通信接口为异步接口，对于同步RPC请求，多线程共享通信队列需要上下文切换，不能满足时延要求。需要设计低时延的同步机制进行上下文切换或无锁设计。  对于TCP而言，协议本身已经提供了流控机制和传输的可靠性，需要额外提供消息的上下文管理，即对发送消息和接收消息进行关联。  UB是无连接的，但与RDMA一样采用发送队列、接收队列和完成队列的方式进行通信，所以会话管理与RDMA一致。  5、消息处理  根据通信接口语义，需定义不同类型的消息，包括集群内节点间RPC通信消息、远端内存访问消息、节点间原子操作消息及集群间RPC通信消息。消息处理组件根据消息类型进行封装、解析为所需的消息类型。后续根据业务需要，对不同消息类型提供序列化、反序列化能力。  6、协议层  协议层需要同时适配RDMA/TCP/UB三种通信协议栈。  对于RDMA协议层的设计需要考虑：多线程并行发送RDMA请求时，并发请求的响应到达顺序与请求顺序不一致，因此不能在发送线程中通过检查CQ来查看自己的响应是否到达（可能先查到其它线程的响应），需要单独一个线程去检查CQ状态，这样就需要在发送线程与检查线程间进行同步，但线程同步机制很难满足时延要求（高并发场景下加解锁可能需要上千至上万个cycle），所以需要考虑协程或者无锁设计。如果使用协程，在线程的协程中轮询完成队列，其他协程进行发送请求，但是需要在业务模块启用协程，通信模块无法控制管理发送线程。如发送端无法采用协程设计，为了降低调度开销，对于有锁设计，CQ检查线程应该单独绑核，通过RDMA协议请求(WR)结构体ibv_send_wr、完成响应(CQE)结构体ibv_wc及响应(WR)结构体ibv_recv_wr三者的wr_id相互关联，该信息可放于双边通信的消息头的msgId字段或单边通信的立即数字段。wr_id是由通信组件传入的参数，可设置为消息的内存地址以避免重复。对于无锁设计，考虑采用run-to-complete模型，即线程间不共享QP，在一个线程内完成消息的发送和轮询事件，但资源消耗更大，更适用于对时延要求极高的单边操作场景。  RDMA原语的轮询CQ接口采用poll实现，对于大并发场景，poll的性能不及专门用于处理有大量IO操作请求的epoll异步编程接口。考虑设计epoll接口访问系统节点，轮询CQ完成队列，取代RDMA原语接口以获取更好性能。  RDMA协议不同传输模式支持的最大传输大小如上表所示， 双边通信可使用不可靠报文以节省内存资源，提高通信效率，但是最大传输数据长度受限于网卡MTU，需要限制发送数据，或者进行拆包发送、组包接收。  11.2.2 集群管理组件 云原生数据库支持全球集群部署和区域集群部署，相应的，故障检测也分为全球集群故障检测和区域集群内故障检测，全球集群故障主要检测区域集群网络故障、区域集群脑裂故障。区域集群内检测节点网络故障、租户节点分区、集群管理节点分区、DFV存储故障。不同的故障需要不同的心跳链路来检测，具体如下图所示。   图4 集群组件心跳架构图  1. DCHA网络心跳，DCHA全称为DeCentralized High Availability，即去中心化故障快速检测方案。DCHA本质是一种邻居故障检测方法，能够更好地适应大规模集群故障检测，但是当大规模集群故障时可能导致漏报问题，需要通过其他机制，比如租约心跳机制作为补充。  2. 节点租约心跳。节点租约心跳故障检测是指节点向集群管理节点获取心跳租约，当集群管理节点检测节点长时间未申请租约，将会判断此节点故障，同时如果节点长时间无法从集群管理节点获取租约，将进行自杀重启。  3. 租户节点间网络心跳和DFV心跳。租户节点间互发网络心跳、写入DFV磁盘心跳，通过Membership Voting Disk机制判断租户脑裂和租户节点故障，并进行租户视图变更和故障重启。  4. 集群管理间心跳根据部署形态选择不同心跳机制。如果是共享存储部署，则选用Membership Voting Disk机制。如果是share nothing单机部署形态，则选择普通心跳，通过Raft协议避免分区。  5. 区域集群间网络心跳。每个区域集群通过Membership Voting Disk的一致性视图选择一个节点或者通过Raft协议选择的主节点当做本区域集群的节点代表与其他区域集群进行通信。区域集群间选择普通网络心跳，通过Raft协议避免区域集群的分区。  6. 如果集群管理服务整体失效，则租户进程不能继续提供服务。如果节点主进程失效，则租户进程也不能继续提供服务。  11.2.3 多租组件 云原生数据库支持多租户，通过多租户资源共享，一是降低租户的成本，二是通过共享资源的池化实现租户的资源弹性，提高租户业务的可用性。租户的资源弹性支持两种模式，Scale Up和Scale Out。Scale Up是在单个计算节点上对租户的分配资源进行弹性处理，Scale Out是在计算节点之间对租户的分配资源进行弹性处理。  Scale Up的弹性模式在计算节点上实现，由计算节点上的多租户资源管理模块实现。Scale Out的弹性模式由集群管理节点的调度模块实现。因此整个多租户设计主要分为两个部分，分别为节点租户资源管理（节点上）和集群资源调度管理（节点间）。  租户购买的资源类型可以是固定型和弹性型。固定型的资源类型总是始终保证的。弹性型对应到Scale Up和Scale Out两种弹性模型。弹性型的资源类型由可变的节点个数和每个节点上可变的资源大小组成，分别表述为租户节点个数最小值和租户节点个数最大值、租户节点资源最小值和租户节点资源最大值。  最小值是始终保证的，弹性是在最小值和最大值之间做弹性伸缩。节点租户资源管理处理节点上租户资源的最小值-最大值之间的弹性；集群资源调度管理处理租户资源总的节点数在租户节点最小值-租户节点最大值之间的弹性。即绝对保证固定资源分配和最小预留资源分配，最小预留到最大上限部分的弹性资源不绝对保证，根据租户的工作负载情况和优先级进行资源调度。  租户节点资源管理和集群资源调度管理的两层整体架构如下：   图5 集群资源调度和计算节点资源管理逻辑图  对于集群资源调度，多个计算节点上的资源组成一个大的资源池，集群资源调度负责整个资源池的管理和调度，比如租户数据库服务初始化部署时一次调度分配资源，以及租户数据库服务迁移的二次调度分配资源。一次调度只关注租户资源配置进行静态的资源调度分配，即根据固定资源，或者最小预留资源设置进行调度。二次调度则是根据租户数据库服务负载统计信息和计算节点负载信息进行调度。  对于节点租户资源管理，云原生数据库采用进程级的资源隔离来实现多租户资源隔离，即在一个计算节点上每个租户拥有一个数据库服务进程。每个计算节点可以看作一个单独小资源池，节点租户资源管理主要负责计算节点上租户的资源分配，资源隔离与弹性控制，以及租户数据库服务的管理，如启动，停止等。  以上内容为云原生关键技术架构&关键技术方案的相关内容，由于关键技术方案部分内容过多，下篇将接着从事务存储组件、SQL引擎组件、DCS组件、实时分析组件等方面继续分享关键技术方案的相关内容，敬请期待！ 

一、前言SQL是用于访问和处理数据库的标准计算机语言。GaussDB支持SQL标准（默认支持SQL2、SQL3和SQL4的主要特性）。本系列将以《云数据库GaussDB—SQL参考》在线文档为主线进行介绍。二、CASE Expression（CASE表达式）介绍在GaussDB SQL中，CASE表达式（CASE Expression）是一个非常强大且常用的工具，可以用于在SQL中执行基于条件的操作。CASE表达式类似于IF-THEN-ELSE语句，但使用起来更加灵活，易于阅读和编写。CASE表达式包含两种形式，一种是简单形式，一种是搜索形式。下面将分别介绍这两种形式的写法、语法以及使用方法。三、GaussDB数据库中的简单CASE表达式1、基本概念简单CASE表达式是指在给定的表达式上执行基于等式的比较，如果表达式等于某个值，则执行某个操作。即依据input_expression与when_expression的匹配结果跳转到相应的result_expression。2、基本语法CASE input_expressionWHEN when_expression THEN result_expression[...n][ELSE else_result_expression]END;说明：其中，input_expression表示需要比较的表达式，when_expression等表示需要比较的值，result_expression等表示各个值相等时的结果，else_result_expression表示当input_expression不等于任何值时的默认结果Tip:CASE：简单CASE函数中支持子查询，但须注意input_expression与when_expression是可匹配的。 另外，如果没有取值为TRUE的input_expression = when_expression，则当指定ELSE子句时，DLI将返回else_result_expression；当没有指定ELSE子句时，返回NULL值。3、示例假设根据固定的工资定义职员级别，可按如下SQL执行：SELECT name,salary,CASE salaryWHEN 15000 THEN '初级'WHEN 20000 THEN '中级'WHEN 25000 THEN '高级'WHEN 30000 THEN '高级'WHEN 35000 THEN '高级'ELSE NULLEND AS levelFROM companyORDER BY salary;SQL语句解析：测试使用的是在GaussDB数据库中创建的一张company表。这段SQL是从“company”表中选择员工的名字（name）、薪水（salary）以及一个根据薪水等级分类的字段（level）。并使用“ORDER BY salary”语句将结果按照薪水从低到高的顺序进行排序。简单CASE表达式的工作方式：如果“salary”字段的值等于15000，那么“level”字段的值就是“初级”。如果“salary”字段的值等于20000，那么“level”字段的值就是“中级”。如果“salary”字段的值等于25000或30000或35000，那么“level”字段的值都是“高级”。如果“salary”字段的值不等于以上任何值，那么“level”字段的值就是NULL。四、GaussDB数据库中的搜索CASE表达式1、基本概念搜索CASE表达式是指在给定的表达式上执行基于不等式的比较，如果表达式满足给定的条件，则执行相应操作。即按指定顺序为每个WHEN子句的boolean_expression求值。返回第一个取值为TRUE的boolean_expression的result_expression。2、基本语法CASE WHEN boolean_expression THEN result_expression[...n][ELSE else_result_expression]END;说明：其中，boolean_expression等表示需要比较的条件，result_expression等表示满足对应条件时的操作结果，else_result_expression表示当expression不满足任何条件时的默认结果。Tip:boolean_expression：可以包含子查询，但整个boolean_expression表达式返回值只能是布尔类型。如果没有取值为TRUE的Boolean_expression，则当指定ELSE子句时，DLI将返回else_result_expression；当没有指定ELSE子句时，返回NULL值。3、示例假设根据工资的范围定义职员级别，可按如下SQL执行：SELECT name,salary,CASE WHEN salary < 15000 THEN '初级'WHEN salary BETWEEN 15000 AND 25000 THEN '中级'WHEN salary >25000 THEN '高级'ELSE NULLEND AS levelFROM companyORDER BY salary;SQL语句解析：这段SQL同上文，是从"company"表中选择员工的姓名（name）、薪水（salary）以及根据薪水等级进行分类（level）。搜索CASE表达式的工作方式：当薪水（salary）小于15000时，薪水等级被标记为"初级"。当薪水在15000和25000之间（包括15000和25000）时，薪水等级被标记为"中级"。当薪水大于25000时，薪水等级被标记为"高级"。如果以上条件都不满足，薪水等级被标记为NULL。综上，这个SQL语句的主要目的是获取员工信息，根据其薪水水平对其进行分类，并按照薪水的水平进行排序。五、小结GaussDB 中的CASE表达式是一个非常有用的工具，可以用于在SQL中执行基于条件的操作，实现条件判断和分支逻辑，进一步优化数据库查询和操作。在编写SQL代码时，可以根据具体的业务需求灵活选择简单形式或搜索形式来进行编写，这样可以大大提高编码效率和代码可读性。附：常见使用场景，如：二次定义标签、饱和度统计、计算指标、数据格式转换等。——结束

一、前言数据库与数据管理有着密切的关系，两者共同构成了一个完整的、可扩展的数据库管理系统。 数据库是用于存储数据的系统，为数据提供了安全、可靠、可扩展和可管理的存储环境。随着信息技术的飞速发展，数据已经成为企业的核心资产之一。在这个数据驱动的时代，数据管理成为了企业追求卓越的关键因素之一。GaussDB数据库作为一款具有高性能、高可用性和高可靠的关系型数据库管理系统，为数据管理提供了强大的支持。二、数据质量规则体系(衡量标准)数据管理最直接的目标是提高数据质量，最终目标是数据价值。主要驱动力是使组织能够从数据资产中获取价值。随着数据类型、数据来源的不断丰富以及数据量的飞速增长，企业面临数据质量问题的概率显著增加。数据质量是一个复杂问题，往往是多种因素综合作用的结果，解决数据质量问题要从机制、制度、流程、工具、管理等多个方面着手发力。数据质量涉及的范围也很广，贯穿业务的整个生命周期，从“数据产生->数据接入->数据存储->数据处理->数据输出->数据展示”，每个阶段都需要质量管理。在数据库系统建设的各个阶段都应该根据标准进行数据质量检测和规范化，及时进行管理，减少事后的治理工作。1. 为什么要进行数据管理举个下面的例子，很多刚入门的数据人，拿到数据后会立刻开始对数据进行各种统计、分析等，企图能立即发现数据背后隐藏的数据价值。然而忙活了一阵发现，并不能立刻提炼出太多有价值的信息。比如和数据打交道，可能会出现以下的场景：场景一：统计近 7 天用户的购买情况，结果从数据库中统计完发现，很多数据存在了重复记录，甚至有些数据统计单位不统一。场景二：查看报表，发现某一天的成交量暴跌，经过排查发现，是当天的数据缺失。场景三：一线坐席人员进行电销业务，拨打客户电话，看到了客户的敏感信息，被客户投诉。场景四：比如未进行数据备份，当数据被误操作、业务系统宕机时造成的数据丢失等。……造成这些情况的一个重要因素就是忽视了对数据的管理，没有制定合理的衡量标准，没有对数据进行审计和安全等管理。导致没有发现数据已出现的问题。所以，进行科学、客观的数据质量规则体系是非常必要且十分重要的。2、数据质量规则体系完整性：指数据在创建、传递过程中无缺失和遗漏，包括实体完整、属性完整、记录完整和字段值完整四个方面。完整性是数据质量最基础的一项，例如员工工号不可为空。唯一性：指同一数据智能有位移的标识符。体现在一个数据集中，一个实体只出现一次，并且每个唯一实体有一个键值且该键值只指向该实体。例如员工有且仅有一个有效工号。有效性：指数据的值、格式和展现形式符合数据定义和业务定义的要求。例如员工的国籍必须是国家基础数据中定义的允许值。一致性：指遵循同一的数据标准记录和传递数据和信息，主要体现在数据记录是否规范、数据是否符合逻辑。例如同一工号对应的不同系统中的员工姓名需一致。准确性：指真实、准确地记录原始数据，无虚假数据集信息。数据要准确反映其所建模的“真是世界”实体。例如员工的身份信息必须与身份证件上的信息一致。及时性：指及时记录和传递相关数据，满足业务对信息获取的时间要求。数据交付要及时，抽取要及时，展现要及时。数据交付时间过长可能导致分析结论失去参考意义。三、GaussDB数据库中如何实现数据管理在GaussDB数据库中，可从如下几方面进行数据管理（包含但不限于）。1、数据质量设计从语法、语义、语用三个方面去定义和衡量数据质量，在数据产生、数据加工以及数据使用的全过程中均需要符合其制定的标准和规范。如下图示：2、数据保护技术GaussDB通过多种数据保护手段和特性，保障存储在GaussDB中的数据安全可靠。传输加密（HTTPS）：支持HTTP和HTTPS两种传输协议，为保证数据传输的安全性，推荐您使用更加安全的HTTPS协议。敏感操作保护：控制台支持敏感操作保护，开启后执行删实例等敏感操作时，系统会进行身份验证，进一步保证GaussDB配置和数据的安全性。SSL数据加密：可以使用SSL来加密数据库GaussDB和客户端的连接。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。3、数据存储GaussDB支持行列数据存储模型方式。进行数据库设计时，表设计上的一些关键项将严重影响后续整库的查询性能。表设计对数据存储也有影响：好的表设计能够减少I/O操作及最小化内存使用，进而提升查询性能。表的存储模型选择是表定义的第一步。客户业务属性是表的存储模型的决定性因素，依据下面表格选择适合当前业务的存储模型。存储模型使用场景行存点查询(返回记录少，基于索引的简单查询)。增删改比较多的场景。列存统计分析类查询 (group , join多的场景)。4、数据加密模型全密态数据库使用多级加密模型，不同加密场景中密钥的功能如下：数据：密态数据库对SQL语句中属于加密列的数据进行加密，对数据库服务端返回的属于加密列的查询结果进行解密。列密钥：数据由列密钥进行加密，而列密钥由主密钥加密。列密钥密文存储在数据库服务端。主密钥：由外部密钥管理生成并存储，数据库驱动会自动访问外部密钥管理，以实现对列密钥进行加解密。5、数据备份GaussDB支持多种数据备份和恢复方式，如全量备份、增量备份和差量备份等。这些备份和恢复方式可以保证数据的一致性和可靠性，避免数据丢失和损坏。备份策略：全量备份：第一次的全量备份后，无论数据是否变化，第二次备份和第三次备份都会将所有的数据全部进行备份。增量备份：第一次的全量备份之后，第二次备份只会备份数据变化的数据，第三次备份只会备份第二次备份后数据变化的数据。差量备份：第一次的全量备份之后，第二次备份只会备份数据变化的数据，第三次备份会备份第一次全量备份后数据变化的数据。GaussDB会在数据库实例的备份时段中创建数据库实例的自动备份。系统根据您指定的备份保留期保存数据库实例的自动备份。扩容实例CN或者分片后，系统会进行一次自动备份。 用户还可以创建手动备份对数据库进行备份，手动备份是由用户启动的数据库实例的全量备份，会一直保存，直到用户手动删除。四、小结GaussDB数据库凭借其高性能、高可用性和高可靠的特点，为数据管理提供了强大的支持。企业应充分利用GaussDB数据库对数据管理的更多功能和优势，加强数据管理实践，不断提升数据质量、数据安全，为企业的发展创造更大的价值。另外，对于数据管理而言，数据库是一种其必不可少且功能强大的数据管理工具。数据管理工作除了依赖数据库外，更多的要结合企业的管理机制、制度、流程、第三方工具等。例如，建立数据管理体系、制定数据管理标准、加强数据使用者的培训、定期进行数据质量管理检查等。——结束

GaussDB for MySQL 支持哪几种数据库引擎

gaussdb 和 openGaussDB 有啥区别

GaussDB for mySQL 中InnoDB引擎 里的 undo log 有什么用

一、前言随着企业数据量的不断增长和业务需求的复杂性增加，选择一个高效、可靠且智能的数据存储和管理解决方案变得越来越重要。GaussDB是一种先进的关系型数据库管理系统，为企业提供了强大的数据处理能力，其物化视图（Materialized Views）功能在数据查询和管理方面具有重要作用。本文以GaussDB数据库为例，将简单介绍一下物化视图的概念、语法及其示例。二、概述物化视图实际上就是一种特殊的物理表，物化视图是相对普通视图而言的。普通视图是虚拟表，应用的局限性较大，任何对视图的查询实际上都是转换为对SQL语句的查询，性能并没有实际上提高。而物化视图实际上就是存储SQL所执行语句的结果，起到缓存的效果。 物化视图在GaussDB数据库中有两种表现形式，分别是全量物化视图和增量物化视图。三、全量物化视图（GaussDB）GaussDB数据库中全量物化视图的概述：全量物化视图仅支持对创建好的物化视图做全量更新，而不支持做增量更新。创建全量物化视图语法和CREATE TABLE AS语法一致，不支持对全量物化视图指定NodeGroup创建。1、语法格式创建全量物化视图CREATE MATERIALIZED VIEW [ view_name ] AS { query_block };全量刷新物化视图REFRESH MATERIALIZED VIEW [ view_name ];查询物化视图SELECT * FROM [ view_name ];删除物化视图DROP MATERIALIZED VIEW [ view_name ];2、示例1）创建测试表，准备测试数据--创建测试表DROP TABLE IF EXISTS company;CREATE TABLE company (id int4 PRIMARY KEY,name varchar(10) NOT NULL,age int4 NOT NULL,address varchar(20) NOT NULL,salary float4 NOT NULL);--插入测试数据INSERT INTO company VALUES (1, 'Paul', 32, 'California', 20000);INSERT INTO company VALUES (2, 'Allen', 25, 'Texas', 15000);2）创建全量物化视图--创建全量物化视图CREATE MATERIALIZED VIEW v_test AS select count(*) as num from company;--查询物化视图结果SELECT * FROM v_test;3）再次向物化视图中源表插入数据，并刷新全量物化视图--再次向物化视图中源表插入数据INSERT INTO company VALUES (3, 'Teddy', 23, 'Norway', 20000);INSERT INTO company VALUES (4, 'ZhangSan', 30, 'BeiJing', 30000);--对全量物化视图做全量刷新REFRESH MATERIALIZED VIEW v_test;--查询物化视图结果SELECT * FROM v_test;4）删除物化视图--删除物化视图DROP MATERIALIZED VIEW v_test;四、增量物化视图（GaussDB）GaussDB数据库中增量物化视图概述：增量物化视图顾名思义就是可以对物化视图增量刷新，需要用户手动执行语句完成对物化视图在一段时间内的增量数据进行刷新。与全量创建物化视图不同在于目前增量物化视图所支持场景较小，目前物化视图创建语句仅支持基表扫描语句或者UNION ALL语句。1、语法格式创建增量物化视图CREATE INCREMENTAL MATERIALIZED VIEW [ view_name ] AS { query_block };增量刷新物化视图REFRESH INCREMENTAL MATERIALIZED VIEW [ view_name ];查询物化视图SELECT * FROM [ view_name ];删除物化视图DROP MATERIALIZED VIEW [ view_name ];2、示例--创建增量物化视图（复用上面的源表company）CREATE INCREMENTAL MATERIALIZED VIEW v_test2 AS SELECT * FROM company;--查询物化视图结果SELECT * FROM v_test2;--插入数据INSERT INTO company VALUES (5, 'LiSi', 28, 'ShangHai', 35000);--增量刷新物化视图REFRESH INCREMENTAL MATERIALIZED VIEW v_test2;--查询物化视图结果SELECT * FROM v_test2;--删除物化视图DROP MATERIALIZED VIEW v_test2;五、物化视图的不足与注意事项1、物化视图的不足物化视图也存在一些不足之处：物化视图需要占用额外的存储空间来存储查询结果，这可能会增加数据库的维护成本。其次，物化视图可能无法实时更新，对于需要实时响应的业务需求可能不够灵活。此外，物化视图的创建和维护需要一定的计算资源和时间成本，对于大规模数据集和高并发查询场景可能存在一定的性能压力。2、物化视图注意事项在使用GaussDB数据库物化视图时，需要注意以下事项：应根据业务需求合理选择物化视图的创建时机和更新策略，避免不必要的计算和存储开销。应充分考虑物化视图的数据来源和查询范围，确保物化视图的数据准确性和完整性。需要关注物化视图的性能表现，对于可能出现性能瓶颈的场景，应采取相应的优化措施。应定期评估物化视图的效用，根据业务变化及时进行调整和优化。3、问题经验示例1）当删除物化视图中的源表时会报错，报错信息如下截图，可参考。2）增量物化视图目前不支持聚合函数，报错信息如下图，可参考。六、小结GaussDB数据库物化视图是一种重要的数据处理工具，它通过预先计算和存储查询结果，极大地提高了数据查询效率。物化视图的优点在于它们可以显著减少查询时间，提高数据处理速度，并支持复杂的查询和分析操作。另外，物化视图还具有可定制性，用户可以根据业务需求自定义查询结果和更新策略。最后，在实际应用中，应根据具体情况充分考虑其优缺点和使用注意事项，以实现最佳的数据管理效果。——结束

gaussDB是否能像mysql一样在windows和linux安装呢，如果可以是在哪里下载相关安装包呢

GaussDB架构介绍（二）从数据持久化存取层(DataNode)关键技术方案、全局事务管理层（GTM）关键技术方案、集群管理层（CM）关键技术方案、OM运维管理关键技术方案等方面介绍了GaussDB架构，本篇将从智能关键技术方案、驱动接口关键技术方案继续解读GaussDB架构。9  智能关键技术方案智能关键技术一：自治运维系统GaussDB 自治运维系统“DBMind”的整体系统框图如下图所示，包含四个维度：数据采集层数据采集层主要功能实现指标数据采集，采集频率分为秒级采集和分钟级采集。其中秒级采集包括操作系统资源信息采集和数据库实例信息采集，例如操作系统层面CPU、内存、IO读写、网络资源信息采集，数据库实例状态、数据库内关键指标（内存、连接数、TPS、QPS、读写频率等）；分钟级采集包括审计日志采集、数据库日志采集和全量SQL流水采集。DBMind数据平台提供Agent进程用于采集上述指标；若客户系统配置普罗米修斯进行信息采集，DBMind提供openGauss-exporter，内置数据库多维度指标采集以及二次数据计算，实现与用户既有普罗米修斯平台对接。数据库采集端程序需要部署在同数据库物理机节点，数据库多节点集群环境中，每个物理节点部署一个Agent采集端（或者普罗米修斯采集端）。数据库采集端程序通常占用资源很少，通过配置文件可以制定不同指标采集频率，以免占用资源影响数据库业务正常运行。图1 DBMind整体系统框架图数据计算层数据计算层提供数据存储、数据分析及元数据管理能力。其中数据存储用于接收来自数据采集层发生来的数据，存储数据源可以是多种维度或者类型，包括普罗米修斯、时序数据库（OpenTSDB）、MongoDB、SQLite等，DBMind内置对接接口，AI模块与存储数据源的交互，获取数据并进行处理。DBMind默认提供SQLite数据库，方便普通开发者来使用AI自治功能；在企业业务中，存储层设计要复杂的多，可以使用多个开源组件组合使用，例如普罗米修斯+时序数据库，或者kafka+时序数据库等多种方案。若企业业务中，处理少量业务集群节点，可通过下面方案实现：图2 小规模节点管控层方案在图2方案，使用nginx进行业务分流，mgrsrv服务对数据进行初步处理后，将数据写入关系型数据库。基于可靠性考虑，对于三个组件，分别加入备机进行可靠性保护。若企业业务处理上万业务节点的数据，图2方案无法满足客户业务诉求。故在方案设计时，需要引入分布式消息中间件、数据库中间件（DDM），同时因为nginx挂载节点有上限，需要对mgrsvr进行分区管理。图3 大规模节点管控层方案如图3所示，consumer服务可以和mgrsvr部署在同一个节点上，mq集合代表分布式消息中间件，通常可以采用开源软件rocketmq或者rabbitmq，引入消息中间件目的是降低目标数据库的压力。DDM是华为云的数据库中间件，若采用开源软件，也可使用mycat或者dble等，可进行存储大规模被采集的数据。在整体业务角度，纵向通过分层设计，横向通过分区设计，保证全部业务可通过管控层完成数据处理。在数据计算层除了时序存储数据库外，还可以设计其他存储单元，例如算法模型库和故障规则库。其中算法模型库存储自治管理服务生成的AI模型，例如参数推荐训练模型；在算法模型库中，可以存储传统机器学习（例如监督学习）模型、强化学习模型。故障规则库是记录数据库常见故障案例，将这些案例通过拆解和分析，生成规则引擎。自治服务层自治服务层包含三个主要部分：SQL诊断和调优、自治安全、数据库智能运维。其中SQL诊断和调优提供多种SQL治理和调优能力，包括慢SQL发现、SQL表现评估、智能索引推荐、智能查询重写等服务。自治安全通过AI技术实现敏感信息发觉、SQL注入检测和异常行为分析。数据库智能运维功能实现在数据库系统、OS系统和数据库集群层面的运维和调优，其中数据库系统服务包括数据库参数智能推荐、智能巡检、数据库分布键推荐和智能业务调度；在操作系统层面，实现慢盘检测和恢复、网络丢包检测；在数据库集群层面，基于故障或者负载需求，提供自动扩缩容、异常节点修复服务。监控展示层DBMind提供监控展示层，通过WEB形式，方便用户直观感受运维管理带来的遍历。在展示界面方面，集成Grafana实现实施数据或指标的展示，同时AI趋势预测，给出后续时段的数据走向。告警界面展示系统中可能存在的问题或故障，分为致命、严重、一般，界面中只显示致命问题。为方便用户系统观察集群状态，提供健康指数报告和详细综合报告。健康指数报告给出当前系统的健康评分等级，默认80分以上属于运行健康状况，小于60分则存在严重隐患，急需修复。综合报告详细描述系统各维度信息，包括集群状态、负载运行情况、常见数据库指标项信息。智能关键技术二：库内AI引擎GaussDB 库内AI引擎架构如下图：图4 DB4AI架构图用户接口层在用户接口层，实现SQL-like语法，提供Create Model、Predict等关键字，支持AI算法训练和预测。当前支持的AI算法包括：GD（梯度下降法）、KMeans（聚类）、XGBoost、决策树等。查询优化层查询优化层提供AI训练执行计划和AI预测执行计划，该计划依据内部统计信息和AI算子调用关系，生成相应执行计划。可以把AI算子看做执行器中的计算单元，例如Join、AGG等，AI算子执行代价基于执行逻辑、获取的数据行数、算法复杂度共同决定。同时在执行计划生成后，可通过Explain语句查看详细的执行开销，分析路径选型的正确性。AI底座和执行层在AI底座中，提供超参优化能力，即用户不指定超参数或者指定超参数的范围，自动选择适合的参数，该功能极大提升用户使用的效率，同时达到最佳的训练性能。在执行器中，提供多种AI算子，例如GD算子可支持逻辑回归、分类；KMeans算子支持聚类。在每个算子实现过程中，遵循执行器算子实现逻辑，下层对接Scan算子，上次提供AI算子的训练或推理结果。在训练完成后，训练模型将实时保存到系统表中，用户可以查询gs_model_warehouse系统表来获取模型信息。存储层在存储层，DB4AI提供数据集管理功能，即用户可以抽取某个表或多个表中的列信息，组成一个数据集，用于后续模型训练。数据集管理功能类似git模式提供多版本管理，目的是保障训练数据的一致性。同时在这过程中，可通过特征处理和数据清洗保障数据的可用性。同时对已生成的模型进行管理，包括模型评估、定期模型验证、模型导入、模型导出等能力，在验证模型失效后，模型漂移功能可以进行模型刷新，保障模型可用。异构计算层DB4AI框架支持异构计算层，实现CPU和AI算力的统一调度，满足数据库语句执行和AI训练的完美结合。在实现方面，CPU算力，特指ARM及X86芯片，可用于基础机器学习算子调用及并行计算执行；AI算子，例如昇腾及GPU芯片，可用于重度分析算子（Join、AGG）及深度学习算子使用，加速大数据及多层网络场景下计算需求。智能关键技术三：智能优化器贝叶斯网络模型原理贝叶斯网络是一种概率图模型，拓扑结构通常为一个有向无环图。贝叶斯网络的优势在于能够利用条件独立假设对多变量数据进行建模，并且自适应变量之间的相关性，具体是指每个变量的概率分布只和与它直接连接的父亲节点有关。使用这种方法能够比基于简单的独立性假设的模型获得更高的建模准确率，也能够比完整的联合分布建模获得更高的执行效率。在关系数据表中，每一列数据都可以成为一个变量，比如下表中包含A,B,C三列数据：表1ABCA1B1C1A1B1C1A1B1C1A2B1C1A2B2C2A2B2C2分别使用基于独立性假设的单列建模和基于条件独立假设的贝叶斯网络计算查询 SELECT * FROM table WHERE A=A1 AND B=B1 AND C=C1的选择率：单列建模：P(A=A1, B=B1, C=C1)=P(A1)P(B1)P(C1)=0.5 * 0.67 * 0.67=0.22贝叶斯网络：P(A=A1, B=B1, C=C1)= P(A1)P(B1|A1)P(C1|B1)=0.5*1.0*1.0=0.5可以看出贝叶斯网络在列相关性强的场景下能够更加准确地估计出多列查询选择率（和基数）。贝叶斯网络结构搜索贝叶斯网络的拓扑结构决定于变量之间的互相关性，直观上看，将互相关性强的变量进行连接并计算条件概率有助于提高分布建模准确性。假设有两列数据A和B，互相关性定义如下：针对例1中的数据，可以计算出A和B列的互相关性：在本功能中，对于P(a,b)，P(a)和P(b)的计算通过使用哈希表统计获得，首先计算单列统计频率，然后计算两列统计频率，最后扫描两列统计表并且通过访问单列统计表获得单列频率，使用公式计算出相关性。最后计算总体相关性。得到的临时表ab_mutual_correlation结构如下所示：表2countacountbcountab343341322遍历上述临时表，对每一行求得互相关性，然后求和之后就是A和B列的整体相关性。贝叶斯网络对于每个节点父亲节点的数量是没有要求的，但是父亲节点越多，条件概率建模的难度也越大，消耗的空间和时间代价也会相应变大。所以在本子系统中，我们只采用树型的网络拓扑结构。这种结构中每个节点只有一个父亲节点，所以只需要保存本节点可以另一个父亲节点的条件概率即可，示例如下：图5在有了树型限制之后，结构搜索空间就少了很多，现在的目标就是找到一颗总互相关性最大的生成树，这里本系统采用chow-liu算法，也是一种加权最大生成树算法，算法流程如下：图6 贝叶斯网络结构搜索流程图根据搜索出的贝叶斯网络结构，构造出包含所有边的字符串，比如”a,b,a,c”或者”a,b,b,c”传入贝叶斯网络算子进行模型创建。贝叶斯网络训练图7 贝叶斯网络训练流程图贝叶斯网络训练过程中，算子首先会遍历一遍样本数据，获得每列数据不同值统计；然后对于每列数据，根据是否是连续数据类型进行数据分桶或者高频值抽取以减小存储和计算代价；对数据分桶采用等高分桶，尽量使每个桶内的频度是相似的，每个桶中范围值下界被存储在数据列表中，NULL值单独作为一个值放在列表最后；连续值高频值抽取会将频度最高的K各元素放置在数据列表中，除此之外的其他元素都被表示为一个通配符号放在列表最后；为了减少查找匹配代价，字符串类型数据会存储一个额外的哈希值；列表中每个元素表示结构如下所示：typedef struct ValueInTuple { Datum data; Oid type; bool isnull; uint32_t hashval;} ValueInTuple;概率建模过程中，针对形如P(离散值|离散值)的条件概率使用概率表记录每种值的概率；针对P(离散值|连续值)，将连续值通过范围分桶当做离散值处理；针对P(连续值|离散值)，使用高斯分布对连续值分布进行建模；针对P(连续值|连续值)，使用高斯分布对条件连续值进行离散化分桶处理，对目标连续值进行高斯分布建模。训练完成之后，将模型序列化成一个二进制字符串。贝叶斯网络模型推理图8 贝叶斯网络推理流程图贝叶斯网络从第一个位置开始获得一个未访问节点，如果该节点存在未访问父亲节点，那么就递归访问父亲节点；如果父亲节点都已经被访问，那么利用条件独立性假设，利用概率表或者是高斯函数局部计算出当前节点的条件概率并且和父亲节点的概率相乘作为联合概率。然后判断当前节点是否是叶子节点，如果是叶子节点则将联合概率和选择率相乘，否则继续寻找下一个未被访问过的节点。最后返回选择率。模型参数缓存策略在基数估计的时候需要获得相应的模型参数，这个过程需要从磁盘读取以及反序列化两种操作，涉及到磁盘访问以及内存申请操作，效率较低，所以在模型数量不多的情况下可以利用全局共享缓存将其存在内存中，下次访问效率就会变高，但是在模型数量变多之后就需要缓存替换策略以保证内存使用是可控的。本子系统采用的是异步批量替换策略，在模型访问亲和性高的场景下，当前一段时间所需要的模型都放置在内存中，不会带来额外的性能损失，访问申请的也都是共享锁支持高并发；当负载偏移之后，新的模型会被访问，从磁盘中被加载到内存，内存中的数量就会超过阈值，这种情况下系统按照每个模型的最近访问时间归一化之后的概率选择1/3的旧模型替换出内存。这种一次性替换多个模型的方法可以避免每次读操作都要申请互斥锁维护链表并且降低替换操作触发的次数。并发analyze场景通过互斥锁进行共享缓存访问控制。10  驱动接口关键技术方案接口驱动兼容开源openGauss, 支持JDBC、ODBC、Python、GO等主流数据库驱动接口，适用于Java/C/C++/python/go 应用程序开发者。对于高级开发者而言，亦可采用libpq动态库接口的方式，对数据库进行接入访问。以上内容为智能关键技术方案、驱动接口关键技术方案的相关内容，下篇图文将接着分享GaussDB云原生架构、关键技术方案的精彩内容，敬请期待！

中奖结果公示感谢各位小伙伴参与本次活动，欢迎关注华为云DTSE Tech Talk 技术直播更多活动~本次活动获奖名单如下：请@Sakura、 于7月8日前在此问卷中反馈您的中奖邮寄信息~直播简介【直播主题】智能优化揭秘 - GaussDB数据库查询重写的自动挖掘与生成【直播时间】2024年6月26日 16:30-18:00【直播专家】王肇国 上海交通大学软件学院副院长Ethan 华为云数据库 DTSE技术布道师【直播简介】在数据库世界里，查询重写是提升性能的关键环节。现有系统依赖人工发现重写规则，过程缓慢且费时。而WeTune的诞生，彻底改变了这一现状！WeTune是一种革命性工具，能自动发现新重写规则，通过枚举和验证等效查询计划，大幅优化查询性能。加入我们的直播，共同探索数据库查询优化的前沿技术，见证性能提升的神奇瞬间！活动介绍【互动方式】直播前您可以在本帖留下您疑惑的问题，专家会在直播时为您解答。直播后您可以继续在本帖留言，与专家互动交流。我们会在全部活动结束后对参与互动的用户进行评选。【活动时间】即日起—2024年6月27日【奖励说明】评奖规则：活动1：直播期间在直播间提出与直播内容相关的问题，对专家评选为优质问题的开发者进行奖励。奖品：华为云定制T恤活动2：在本帖提出与直播内容相关的问题，由专家在所有互动贴中选出最优问题贴的开发者进行奖励。奖品：华为云定制Polo衫​更多直播活动直播互动有礼：官网直播间发口令“华为云 DTSE”抽华为云定制雨伞等好礼。​【注意事项】1、所有参与活动的问题，如发现为复用他人内容或直播间中重复内容，则取消获奖资格。2、为保证您顺利领取活动奖品，请您在活动公示奖项后2个工作日内私信提前填写奖品收货信息，如您没有填写，视为自动放弃奖励。3、活动奖项公示时间截止2024年6月29日，如未反馈邮寄信息视为弃奖。本次活动奖品将于奖项公示后30个工作日内统一发出，请您耐心等待。4、活动期间同类子活动每个ID（同一姓名/电话/收货地址）只能获奖一次，若重复则中奖资格顺延至下一位合格开发者，仅一次顺延。5、如活动奖品出现没有库存的情况，华为云工作人员将会替换等价值的奖品，获奖者不同意此规则视为放弃奖品。6、其他事宜请参考【华为云社区常规活动规则】。

GaussDB架构介绍（一）从GaussDB关键架构目标、GaussDB分布式架构、数据计算路由层（Coordinator）关键技术方案等三方面对GaussDB架构进行了介绍。本篇将从数据持久化存取层(DataNode)关键技术方案、全局事务管理层（GTM）关键技术方案、集群管理层（CM）关键技术方案、OM运维管理关键技术方案等方面继续解读GaussDB架构。4 数据持久化存取层(DataNode)关键技术方案Datanode节点主要负责数据的持久化和快速写入、读取。数据持久化采用物理日志wal，事务提交wal刷盘， 对外提供逻辑日志功能，反解析物理日志为SQL逻辑日志。图1 datanode数据持久化Astore：存储格式为追加写优化设计，其多版本元组采用新、老版本混合存储方式。当一个更新操作将老版本元组更新为新版本元组之后，如果老版本元组所在页面仍然有空闲空间，则直接在该页面内插入更新后的新版本元组，并在老版本元组中记录指向新版本元组地址的指针。在这个过程中，新版本元组以追加写的方式和被更新的老版本元组混合存放，这样可以减少更新操作的IO开销。然而，需要指出的是，由于新、老版本元组是混合存放的，因此在清理老版本元组时需要从混杂的数据中挑出垃圾数据，清理开销会比较大。同时，由于新版本元组位置相对老版本元组位置发生了变化，而索引中只记录了老版本元组的位置，因此容易导致索引膨胀。为了缓解索引膨胀这个问题，对于同一个页面内的更新，采用了HOT技术，将同一个记录的多个版本按从老至新的更新顺序给串连起来，但是这种从老至新的更新链顺序，对于并发的OLTP类短查询是效率是比较低，需要遍历的版本个数较多。Ustore：与astore相比，ustore的最大特点在于新、老版本记录的分离存储。当一个更新操作将老版本元组更新为新版本元组之后，直接在老版本元组的位置覆写新版本元组内容，同时，将老版本元组移到统一管理历史版本的undo区域。在这个过程中，既需要修改数据页面，也需要修改undo页面，更新操作开销较astore的追加更新稍大。但是，就如同垃圾分类回收一样，这样带来的好处也是显而易见的，在清理老版本元组时，不再需要遍历扫描主表数据，直接按需回收undo区域即可，垃圾清理开销较astore不仅大幅降低，而且稳定可控。同时，由于新版本元组复用老版本元组的物理位置，因此索引无需更新，索引膨胀得到有效控制。另外，在ustore中，多个版本的更新链按从新至老的顺序串连，对于并发查询更友好。总而言之，ustore更适合更新频繁的业务场景。5 全局事务管理层（GTM）关键技术方案GTM 仅处理全局时间戳请求， 64位CSN递增，几乎都是CPU ++和消息收发操作。不是每次都写ETCD,  而是采用定期持久化到ETCD 里， 每次写ETCD的CSN要加上一个backup_step (100w), 一旦GTM故障，CSN从ETCD读取出来的值保证单调递增。当前GTM 只完成CSN++,  预估可以支持200M/s 请求。GTM处理获取csn消息和csn++的消息, TCP 协议栈消耗CPU会非常严重，采用用户态协议栈提高GTM单节点的处理能力。未来架构演进完全去中心化，采用高精度时钟解决扩展性问题。5.1 单节点的事务图2 单节点事务处理流程关键设计：GTM 只维护一个CSN++,  snapshot 只包含CSNDN 本地维护事务id, 维护id到CSN的映射(CSN_LOG)DN 本地GC的过程中回填CSN单shared读事务使用local snapshot：get local latest CSN + get prepared_xidwait csn commit in process(same as before)如果row.csn < localsnapshot.csn || xid in prepared_xid list 可见,  否则不可见5.2 跨节点事务图3 跨节点事务处理流程关键设计：第二阶段Commit 改为异步方式，只同步做prepare xact。（1.5 PC）DN 上行级别可见性判断：DN处于prepared状态的事务依赖对应CN上的事务是否提交，如果已经提交，且CSN比snapshot.CSN小，就可见对DN上处于prepared的事务，CN上的事务不处于提交状态，则必须判断是否残留状态，回滚。6 集群管理层（CM）关键技术方案GaussDB Kernel V5 集群管理层关键模块如下。图4 集群管理层组件设计图CM 组件提供了四种服务 CM Agent, CM Server, OM Monitor, cm_ctl，与各类实例服务组件（CN, DN, GTM 等）一起构成了整个数据库集群系统。cm_ctl通过命令行执行集群的启动、停止、状态查询、主备倒换、备机重建等功能除启动和停止外，主要通过与 CM Server 的消息传递执行命令可在任意节点执行并获取到相同的结果OM Monitor由系统定时任务拉起负责 CM Agent 的运行状态监控CM Agent由 OM Monitor 拉起负责拉起和停止所在节点的 CN, DN, GTM, CM Server（如果存在）；监控实例状态并上报至 CM Server；执行 CM Server 下发的命令等对应 cm_agent 二进制文件，所有节点常驻服务CM Server由 CM Agent 拉起，是整个集群管理组件的大脑负责接收 cm_ctl 发送的命令并下发至 CM Agent；接收并处理 CM Agent 上报的实例状态，下发仲裁指令保证各类故障和异常场景下集群的可用性对应 cm_server 二进制文件，常驻服务CM与各类组件的主备数据同步、倒换、重建等机制高度融合，提供告警、重启、倒换、隔离等手段，赋予数据库实例故障恢复及自愈的高可用（HA）能力，保证数据的可靠性和完整性，最终实现集群对外的业务连续性。集群管理仲裁关键技术单节点故障在生产过程中，不可避免。CM 组件可根据探测到的状态进行仲裁，从而尽可能恢复集群可用性的过程。以某个主 DN 故障为例，一次典型的仲裁流程包括：① CM Agent 1探测DN主实例并发现故障② CM Agent 1持续上报实例故障信息至CM Server③ CM Server执行仲裁流程，选择DN备机升主④ CM Server下发升主命令至CM Agent 2⑤ CM Agent 2对实例执行升主操作图5 集群管理仲裁过程常见的故障类型包含磁盘故障、网络故障、下电故障、操作系统故障、其它故障（CPU故障）等。CM在选举过程中，遵从DN多数派。即，对于某一个DN分片来说，故障后的选主，需要得到大多数DN的投票，候选DN副本才可以被选中升主。仲裁规则主要依据两个原则：1） 任期（Term）大，且日志长的DN副本优先被选主 2） 同等条件下，静态主优先。CM辅助不同组件故障情况下恢复过程1.  CN 故障 （集中式部署时，无CM节点）DDL 语句无法执行，DML 语句不受影响通过将故障 CN 剔除，可保障 DDL 语句不受影响仅支持集群内 CN 个数大于 3，且 1 个 CN 发生故障时剔除2.  DN 故障单点故障可自动恢复主 DN 故障时，仲裁备 DN 升主继续提供服务备 DN 故障时，主 DN 将日志和数据同步至从备，业务不受影响3.  主 GTM 故障备 GTM 升主后继续提供服务4.  主 CM Server 故障备 CM Server 接受多数派 CM Agent链接，升主后继续提供服务异常检测从业界经验来看，数据库实例可能处于故障、僵死、亚健康等状态。这些状态的出现概率逐级降低，但检测难度逐级增高。尤其是如何区分亚健康状态和系统繁忙状态，具有较大的挑战性。CM 组件包含异常检测流程，可用于识别和处理网络不稳定、磁盘 IO 挂死、进程/线程僵死、进程频繁退出、实例状态时好时坏等场景，提高集群的稳定性和可用性。以 DN 短链接检测为例，CM Agent 按照固定时间间隔与 DN 实例新建链接。如果与某个主 DN 链接失败或通过新链接无法执行 SQL 语句，则认为该 DN 发生 1 次 Hang 异常。如果多次出现异常，则会触发 Hang 检测机制，将该 DN 实例杀死并执行主备切换。目前常见的异常检测项有：短链接建立通过短链接执行 SQL 语句IO 挂死内存占用异常基于Paxos协议复制实现DN副本自仲裁GaussDB Kernel V5 采用基于Paxos协议主备副本复制协议，实现DN副本的自仲裁功能。关键技术方案如下图所示，其中DCF为GaussDB Kernel V5 基于Paxos协议的一致性复制组件。需包含日志复制、自仲裁选主等功能。图6 DN自仲裁设计关键技术方案要点：1）DN 副本自仲裁，缩短仲裁链路，减小RTO  2）采用Paxos一致性协议，保证DN副本间的一致性，避免备机由于日志分叉产生增量重建。未来技术方案演进：1） DCF组件日志与数据库内核日志合一，减少对IO的占用。2） 采用Parallel Paxos协议或者多主的Paxos协议提升日志复制的吞吐量 3）通过RDMA/UB 网络优化主、备节点日志传输，提升日志复制性能。7 OM运维管理关键技术方案GaussDB Kernel V5 OM运维管理关键模块如下。OM 运维主要功能有：安装升级节点替换扩容、缩容自动告警巡检备份恢复、容灾日志分析系统在华为云的部署模式下，OM相关组件部署示意图如下：图7 华为云OM运维管理用户登录华为云Console，访问GaussDB Kernel V5的管控页面，输入想要的运维操作（购买实例）。华为云Console调用云管控服务，云管控服务根据用户输入的运维操作，如购买实例，进行相应的操作，如购买实例，云管控服务会创建虚拟机。云管控服务调用Mgr Agent，Mgr Agent会调用内置插件Adapter。Adapter会调用OM Agent。OM Agent会调用OM来完成具体的运维操作。通过OM Adaptor和OM Agent 采用适配器模式设计，对管控面提供了统一的北向接口。降低了管控面平台变更后重新对接的难度，更适用于云平台下的开发模式。8 安全关键技术方案安全关键技术一：密态等值查询密态等值查询属于密态数据库第一阶段方案，但是遵从密态数据库总体架构。密态数据库的总体架构示意图如下图所示。密态数据库的完整形态包括密码学方案和软硬结合方案。图8 密态数据库总体架构由于密态等值查询仅涉及到软件部分，仅需集成密态数据库总体架构的软件部分，其总体实现方案如下图所示。图9 密态等值查询总体方案从总体流程上来看，数据在客户端完成加密，以密文形式发送到GaussDB Kernel数据库服务侧，即需要在客户端构建加解密模块。加解密模块依赖密钥管理模块，密钥管理模块生成根密钥(RK, Root Key)和客户端主密钥(CMK，Client Master Key)，有了CMK，可以通过SQL语法定义列加密密钥(CEK，Column Encryption Key)。其中，CMK由RK加密后保存在密钥存储文件(KSF，Key Store File)中，与RK一起由KeyTool统一管理；CEK则由CMK加密后存储在服务端，加密算法使用AES128和AES256。按照原有明文格式发送至服务端。当查询任务发起后，客户端需要对当前的Query进行解析，如果查询语句中涉及加密列，则对对应的列参数(加密列关联参数)也要进行加密(这里说的加密均需要为确定性加密，否则无法支持对应的查询)；如果查询语句中不涉及加密列，则直接发送至服务端，无需额外的操作。在数据库服务侧，加密列的数据始终以密文形态存在，整个查询也在密文形态下实现。对于第一阶段密态等值查询解决方案，需要采用确定性加密，使得相同的明文数据获得相同的密文，从而支持等值计算。按照用户使用的流程，整体设计思路将围绕用户的使用步骤展开，即整个Use Case被切分成三部分。具体如下：生成客户端主密钥：用户需要在本地部署密钥管理工具（KeyTool），通过密钥管理工具相关指令来管理密钥，如创建或删除密钥；当前该工具底层集成华为公司KMC组件，生成的主密钥通过KMC进行保存和管理，并返回密钥信息给用户，方便后续调用和管理；记录CMK与CEK信息，在系统创建加密表：有了阶段1中生成的密钥信息后，为数据库设计专门的密钥创建语法，包括设计新的主密钥(CMK, Client Master Key)和列加密密钥(CEK, Column Encryption Key)语法；通过内核接口访问KeyTool中存储的主密钥并记录在系统中，列加密密钥则由主密钥在客户端完成加密后存储在数据库服务端；数据通过列加密密钥完成在客户端的加密，然后传输到服务端。为了做到查询对用户的透明，需要基于当前已有的创建表语法进行改造，主要进一步增强列的option信息；完成密态等值查询：为了完成密态等值查询需要在客户端和服务端完成配合设计。其中在客户端需要设计轻量级的解析模块，完成对查询语句的解析，定义密态等值查询所支持的规格。在客户端解析模块，需要识别所有涉及的属性是否包含加密列信息，如果不涉及则直接返回并将查询发送到服务端，如果涉及加密列，则需要按照对应的列加密密钥和加密算法加密参数信息，然后发送查询任务到服务端。在服务端，需要在优化器和执行器的各个执行逻辑过程中完成功能适配，特别的，数据在经过加密后，存储的数据类型发生变更，在服务端需要根据新的存储类型进行查询任务执行。安全关键技术二：账本数据库防篡改数据库的整体方案如图10所示，其最终形态是多个数据库之间的多方共识系统。我们基于GaussDB Kernel数据库，从存储层、应用层和传输层进行改造和增强。存储层为防篡改用户表增加校验信息，作为篡改校验的基础能力；应用层提供高效篡改校验接口，使用高性能校验算法，能够快速识别出用户表、用户历史表以及全局区块表的一致性，有效识别篡改行为；传输层增加多方共识执行接口，并内置CFG、BFT等共识算法，使得系统中，每一次对防篡改用户表的修改都需要取得大多数参与方的认可和记录，保证核心数据的防篡改、可追溯。图10 防篡改数据库总体方案账本数据库属于防篡改数据库第一阶段方案，是防篡改数据库的单集群形态，主要是实现了存储层、执行层的功能，提供了用于防篡改校验数据以及高效篡改校验算法。账本数据库作为防篡改数据库整体方案的基础功能和核心能力，需要紧密结合内核并利用分布式数据库的执行框架和通信流程。我们采用schema对防篡改用户表和普通表进行隔离。用户在防篡改schema中创建的表会成为防篡改用户表，防篡改用户表与普通表最大的差别是防篡改用户表会在创建时自动添加名为hash的系统列。hash列在用户插入数据时，自动通过单向加密哈希算法生成。同时在创建防篡改用户表时，会在blockchain系统schema中创建与之一一对应的用户历史表。用户对防篡改表进行DML操作，造成的行级数据更改记录会记录在对应的用户历史表中，同时会将sql语句记录在全局区块表中，作为操作的记录。防篡改用户表、用户历史表、全局区块表中的hash摘要信息可以相互校验，如果校验通过，则视为用户表未被篡改。需要特别说明的是，我们通过判断数据的一致性来识别篡改行为，不能防止恶意用户从文件层一致的修改多个文件以及越权用户通过sql语句对用户表进行修改。账本数据库的功能主要分为三个部分：防篡改用户表的DDL和DML操作、防篡改用户表的一致性校验以及校验数据的归档和修复功能。首先我们介绍防篡改特性的隔离级别，我们使用schema来隔离普通用户表和防篡改用户表。通过增加创建防篡改schema的语法: CREATE SCHEMA schema_name WITH BLOCKCHAIN，在防篡改schema中创建的表，均为防篡改用户表。其次是用户表的DDL和DML操作，在创建防篡改用户表的过程中，主要有两点修改：1. 对该表增加一个名为hash的伪列，该列类型为uuid16，该列记录和每一行数据的校验信息。2. 生成防篡改用户表对应的用户历史表，用户表中记录了行级数据的修改记录。以上内容为数据持久化存取层(DataNode)关键技术方案、全局事务管理层（GTM）关键技术方案、集群管理层（CM）关键技术方案、OM运维管理关键技术方案和安全关键技术方案的相关内容，下篇图文将接着分享智能关键技术方案、驱动接口关键技术方案的精彩内容，敬请期待！