1 GaussDB架构概览

1.1 GaussDB 关键架构目标

        GaussDB在架构设计上，采用组件化原则，分为GaussDB Kernel内核和GaussDB Kernel OM两部分。在产品形态上，提供面向云数据库服务GaussDB（for openGauss）的分布式安装包和集中式安装包，提供面向本地化安装的小型化安装包。

        根据华为云提供的调查报告，当前全球数据库市场增长超预期，云是数据库增长最重要驱动力。得益于云数据库的迅猛发展，AWS市场份额超越IBM，成为数据库市场空间第三位，聚焦公有云、混合云构筑具备竞争力的可商用分布式数据库版本，数据库已成为公有云Top收入来源，同时通过数据库服务能够更大地提升公有云服务粘性。GaussDB Kernel面向云服务提供GaussDB产品，主要客户包含金融（银行、证券、保险）行业、政府（政务云、财政等）和大企业客户。结合产品可信要求定义及可信实施策略分析的内容，以及业界数据库厂商前沿动态，GaussDB Kernel在云服务场景中的架构目标按照一下几个维度来展开：

1. 高性能：建立基于x86平台与鲲鹏平台的绝对性能领先，鲲鹏平台相对x86平台保证50%性能优势，达到单机170万tpmC，分布式全局强一致32节点1500万tpmC，承载用户关键业务负载；具备性能韧性能力，5倍压力下性能不抖动、十倍压力下系统不崩溃，同时具备抗过载逃生能力；具备大并发、低时延能力，单节点支持1万并发、单集群支持10万级并发访问请求，ms至秒级事务处理时延，支撑政企客户核心业务负载。
2. 云原生：通过GTM-Lite技术轻量化处理全局读一致性点与写一致性点，集群扩展性达到256节点，未来通过全球时钟技术演进，在跨Region全局一致性下去除单点瓶颈；面向业务陡增等业务场景，构建基于哈希聚簇的存储结构和弹性扩容方案，实现秒级存储节点扩缩容和业务无感的计算节点弹性伸缩；构建分布式备机只读技术，只读性能提升100%以上。
3. 高可用：AZ内主备高可用，1主多备，RPO=0、RTO
4. 高安全：继承可信实施策略中安全可信需求，从安全，韧性，隐私等维度构筑安全可信能力，结合业界安全技术前沿发展，设计全密态数据库和防篡改数据库，保证用户敏感数据免于泄露和篡改；构建数据库安全自治管控方法，识别和拦截攻击者的异常行为；构建从接入、访问控制、加密到审计全方位纵深防御的安全防护体系。
5. 高智能：面向云化场景故障运维诉求，基于AI技术，提供端到端自治运维管理能力，全面提升数据库产品服务可靠性和可用性；构筑自学习数据库内核，尤其是智能优化器，解决数据库内优化执行过程中计划不准、无法自适应等难题；结合业界前沿技术，构建库内AI引擎，基于SQL-like简易语法，提供数据库内置的机器学习训练和推理能力，为用户提供普惠AI；提供向量数据库能力，支撑盘古大模型、NAIE-NetGPT和GTS领域知识库等场景，提高大模型的预测效率。

        GaussDB Kernel提供的本地化版本的架构目标包括：

• 高性能：支撑业务1千并发能力，性能达1000+ TPS；
• 高可用：提供多种部署形态的能力：一主一备、一主多备等；
• 高安全：支持数据库备份加密、网络连接安全管理及传输加密；支持三权分立，即数据库管理员、安全管理员、审计管理员权限职责分离；支持访问控制；
• 高智能：提供丰富高效的DFx运维监测手段，后续朝向基于AI的自治运维调优方向发展，降低BCM相关产品或解决方案的运维成本，提升易用性；
• 小型化：数据库安装包大小

        GaussDB采用了分层解耦、可插拔架构,能够同时支持OLTP、OLAP业务场景。

1.2 数据库架构变化

        数据库架构经历了几个大的变化: 单机数据库、集群数据库、云分布式数据库。GaussDB面向云分布式数据库设计,采用分层解耦、可插拔架构,一套代码,同时支持OLTP、OLAP业务场景,如下图所示。

图1 数据库架构变化

1.3 GaussDB关键技术架构

        GaussDB采用分布式关键技术架构,实现一套代码同时支持OLAP和OLTP业务场景。主要特点如下:

• 支持SQL优化、执行、存储分层解耦架构。
• 基于GTM(Global Transaction Management,全局事务控制器)和高精度时钟的分布式ACID强一致。
• 支持存储技术分离,也支持本地磁盘架构。
• 支持可插拔存储引擎架构。

        GaussDB未来关键技术架构,如下图所示。

图2 GaussDB未来关键技术架构

2 GaussDB OLTP与OLAP数据库架构

2.1 GaussDB OLTP数据库架构

        OLTP是传统的关系数据库的主要应用，包括基本的增加、删除、修改、查询事务处理，例如银行交易。

2.1.1 设计思想与目标客户

        OLTP业务场景主要分为两大类：一类是金融银行业务场景，一类是互联网业务场景。但应用OLTP业务要满足5个重要的需求：

• 故障业务中断时间,RTO(Recovery Time Objective,恢复时间目标,指业务停止服务的最长时间)尽可能短,最好是RTO=0；
• 任何故障,数据不错、不丢失,RPO(Recovery Point Objective,数据恢复点目标,指业务系统的数据丢失量)=0；
• 并发和性能满足业务诉求；
• 易于运维,最好是自动诊断、自动修复；
• 易于调优,最好是自调优；

        GaussDB OLTP数据库基于这5个关键需求设计，分层解耦：

• 采用并行恢复和存储层异步回放机制优化RTO,目前支持AZ(AvailabilityZone,可用区域)内RTO；
• 采用多副本RAFT(一种分布式一致性协议)复制机制保证数据的可靠性，即RPO=0；
• 支持线程池和采用高精度时钟去中心化，支持高并发和线性扩展性，满足高并发和性能的诉求；
• 运维能力上基于统计数据分析、推理，实现自运维能力，降低运维门槛；
• 采用基于AI的自调优参数和ABO(AI Based Optimization,基于人工智能的查询优化)优化器提供自调优能力，降低调优门槛。

2.1.2 分布式强一致的架构

        分布式强一致必须有一个全局的时间戳信息，否则很难保证数据的一致性。GaussDB 实现了基于GTM 的分布式ACID[原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)]设计。

        GTM 仅处理全局时间戳请求，CSN(Commit Sequence Number,待提交事务的序列号)是一个64位递增无符号数,它的递增,几乎都是CPU++ 和消息收发操作。

        不是每次都写ETCD(Editable Text Configuration Daemon,分布式键值存储系统，用于共享配置、服务注册和查找)，而是采用定期持久化到ETCD。每次写ETCD的CSN 要加上一个backup_step(100万),一旦GTM 出现故障,CSN 从ETCD 读取出来的值保证单调递增。当前GTM 只完成CSN++ ,可以支持200MB/s请求。GTM处理获取CSN消息和CSN++的消息,TCP协议栈消耗CPU 会非常严重,采用用户态协议栈提高GTM 单节点的处理能力。GTM 关键数据结构和线程,如下图所示。

图3 GTM 关键数据结构和线程

2.1.2.1 单节点的事务

        单节点事务设计,如下图所示。

图4 单节点事务设计

        关键设计如下:

• GTM 只维护一个CSN++ ,快照(snapshot)只包含CSN。
• DN(Data Node,数据节点)本地维护事务ID(唯一标识符),维护ID 到CSN的映射(CSN_LOG)。
• DN本地垃圾回收的过程中回填CSN。
• 单分片读事务使用本地快照:

2.1.2.2 跨节点事务

        跨节点事务设计,如下图所示。

图5 跨节点事务设计

关键设计如下:

• 第二阶段事务提交改为异步方式,只同步做两阶段提交的准备阶段。
• DN 上行级别可见性判断:

TRY_AGAIN

IF row xact_status is prepared
{
    notify clean_pending_prepared_xact
    IF CN xact_status is committed && CN xact CSN snapshot CSN
        return visible
    goto try_again
}
Else
{
    if row xact is committed and row CSN snapshot CSN
        return visible
    Else
        return not_visible
}

2.1.3 可插拔存储引擎架构

        面向OLTP不同的时延要求,需要的存储引擎技术是不同的。例如在银行的风控场景里,对时延的要求是非常苛刻,传统的行存储引擎的时延很难满足业务要求。因此GaussDB设计支持了可插拔存储引擎架构,可以同时支持传统行存储引擎和内存引擎。内存引擎采用记录(record)的组织方式,Masstree无锁化索引设计,提高系统并发能力和降低了事务的时延。行存储引擎可以支持不同的MVCC(多版本)实现机制,包括append-only形式的MVCC实现机制和in-place update的MVCC实现机制。整个数据库中存储引擎、SQL引擎都是解耦的,可以快速添加(演进)新的存储引擎和SQL引擎。

2.2 GaussDB OLAP数据库架构

        OLAP是数据仓库系统的主要应用,支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。

2.2.1 设计思想与目标客户

        OLAP数据分析场景有5个关键的需求:

• 数据量大，从几百万亿字节(TB)到千万亿字节(PB)是很正常的，容量可扩展。
• 复杂查询多，计算复杂度高，必须分布式并行计算；
• SQL自动优化能力要强，自动调优诉求强烈。
• 数据入库速度要快，入库几百兆字节、万亿字节的数据很常见。
• 故障恢复RTO 尽可能短，数据不丢失，即RPO=0。

        银行数据仓库、安全行业的同行同住分析、证券行业的数据挖掘分析都对集群的规模和并行计算能力有很高的要求。GaussDB OLAP针对这几个关键需求设计，支持了列存储引擎、自适应压缩，大大降低了存储空间，基于share nothing架构，线性扩展，解决了千万亿字节(PB)级数据存储问题。

        通过分布式优化器和分布式执行器，构筑了分布式并行技术能力。数据入库采用并行加载技术，大大提高入库效率。

2.2.2 面向数据分析的高效存储和计算架构

        GaussDB OLAP数据库采用列存储引擎提高存储的压缩比和面向列的计算能力，而向量化执行相对于传统的执行模式改变是对于一次一元组的模型修改为一次一批元组，且按照列运算，这种看似简单的修改却带来巨大的性能提升。

• 一次一元组模型函数调用次数较大，每一条元组都会根据执行树的形态遍历执行树，面对OLAP场景，一次一元组模型巨量的函数调用次数使开销较大，而一次一批元组的执行模式则大大减小遍历执行节点的开销。
• 一次一批元组的数据运载方式为某些表达式计算的SIMD(Single-Instruction,Multiple-Data stream processing,单指令流多数据流)化提供了机会,SIMD 化能带来性能的提升。
• 一次一批元组的数据运载方式天然对接列存储，列存储引擎能够很方便地在底层扫描节点装填向量化的列数据。CPU 的指令缓存(cache)和数据缓存的命中率大大提高。

        GaussDB OLAP高效存储和计算架构,如下图所示。

图6 GaussDB OLAP高效存储和计算架构

2.2.3 分布式并行计算架构

        分布式并行计算架构核心实现如下:

• 通过分布式优化器，根据代价估算、AI数据分析，产生最优的分布式执行计划。好的执行计划和差的执行计划在运行性能上可能会有很大的差距。优化器生成执行计划的过程如下图所示。

图7 优化器生成执行计划的过程

        GaussDB 0 OLAP数据库优化器支持CBO(Cost Based Optimization,基于代价的查询优化)和ABO(基于机器学习的查询优化),根据代价和AI学习,会自动选择SMP(Symmetric Multi-Processing,对称多处理结构)、Join order、group算法、index等,GaussDB OLAP优化器整体架构如下图所示。

图8 GaussDB OLAP优化器架构

• 通过LLVM(Low Level Virtual Machine,一个编译器框架)编译执行、SIMD单指令多数据执行、算子并行执行和节点并行执行技术,提高复杂查询的性能。

        复杂查询性能提升方式如下图所示。

图9 复杂查询性能提升方式

2.2.4 并行数据加载

        通过并行重分布(Redistribute Streaming)算子技术,让各个DN 都参与数据导入,充分利用各个设备的计算能力及网络带宽。并行数据加载的关键技术如下:

• GDS: 数据源服务进程。
• 重分布: 从GDS读取数据,计算
• 协调节点: 根据数据源和数据节点个数,产生并行重分布的计划,把数据源和数据节点分配好。

        并行数据加载方式，如下图所示。

图10 并行数据加载

2.3 GaussDB云数据库架构

        云数据库系统的主要目的是提供数据库系统服务的基础设施,以实现对计算机资源的共享。本文所讲述的GaussDB云数据库架构设计的内容,目前处于研发阶段,对应产品尚未向客户发布。

2.3.1 设计思想与目标客户

        从数据存放的位置来看,云数据库系统可以分成三大类:

• 公有云数据库系统服务: 该类数据库系统服务主要面向中小型企业的数据库需求。针对中小型企业提供公有云数据库系统服务,可以大幅降低这类公司的运营成本,比如构建数据中心或者机房、构建服务器、运维服务器、运维数据库系统的成本等,同时也使得这类使用公有云数据库系统服务的公司,可以更加专注在业务领域,而无须花费太多的精力在基础设施的构建上。
• 私有云数据库系统服务: 该类数据库服务主要面向大中型企业的数据库服务需求。这类云数据库系统的构建,通常需要在公司内部购买大量的设备,同时构筑相关的PaaS层、SaaS层,其中数据库服务是非常关键的一类服务。该类服务使得公司内部的各个部门的信息新系统可以共享相关资源,同时实现数据共享,并降低整体的维护成本,最终降低总体拥有成本。
• 混合云数据库系统服务: 这类数据库服务同时包含公有云数据库系统服务和私有云数据库系统服务两类。至于哪部分数据库系统服务选择公有云服务,哪部分数据库系统服务选择私有云服务,主要从降低系统的总体拥有成本(Total Cost of Ownership,TCO)上考虑,包括构建成本、运维成本、折旧费用等。

        应该选择哪种云数据库服务,主要从如下3个层面权衡。

• 成本。当企业的系统规模不是很大,通常情况下租用公有云数据库系统服务的成本会低于在企业内部构建数据库系统服务的成本,但是当系统规模扩大到一定程度,在企业内部构建私有云的成本会比购买公有云服务的成本低。当前规模稍大的物联网企业,如今日头条、美团等均是构建企业内部的云服务。
• 差异化竞争力。如果企业对外竞争力构筑在数据库系统服务的基础上,那么企业也将构筑自己的私有云数据库系统服务。
• 数据的隐私度及价值。如果数据是企业的重要资产和核心竞争力,那么这类企业大多会采用基于私有云的数据库系统服务,以更好地保护数据及个人隐私。

        通过上述的分析,中小型企业通常在成本、竞争力构筑、数据隐私保护这几方面权衡后,更大概率地选择公有云数据库系统服务,而大中型企业则更大概率地选择私有云数据库系统服务或者混合云数据库系统服务,其中成本因素会占据比较高的比重。GaussDB云数据系统的目标客户主要是大中型企业。

        大中型企业对云数据库系统的需求与中小型企业对云数据库系统服务的需求有较多的不同之处,具体分析如下:

• 具有更加高效的资源整合和利用能力。对于大中型企业,通常会管辖多个部门,这些独立部门有独立的、不同的业务,为此每个部门均针对各自不同的业务,配备不同的数据库系统,并由此提供数据库系统服务; 另外,对于大中型企业,为了更好地服务各个业务部门,通常会组建平台部门,并为业务部门提供更好的数据库系统服务支持。为了提升整个企业对计算
• 对数据库系统的规格,特别是SLA(Service Level Agreements,服务水平协议)有更加严格的要求。大中型企业通常服务的客户数量大,业务重要,因此对数据库服务请求的吞吐量、每个请求的响应时延、容量扩展速度、计算
• 大中型企业内部多个部门之间的业务并不是完全独立的,通常各自系统之间存在着一定的耦合关系。这类耦合关系,通常表现在数据库表模式之间的耦合关系、数据对象之间的一致性问题、数据之间流动关联关系(Extract Transform Loadworkflow,ETL)。例如某银行,需要通过数据中台维护各个部门之间数据表模式的一致性。
• 具有对新应用的快速迭代和快速开发需求。为了能够加速新应用的开发,在云场景下对数据库系统的克隆、回溯、合并等能力提出了新的需求。特别是在大数据

2.3.2 弹性伸缩的多租户数据库架构

        为了能够适应各类大中型企业对云数据库系统的需求,GaussDB云数据库系统提供了更强的存储资源、计算资源之间的组合能力。其主要目的是实现存储资源的独立扩容和缩容能力、计算资源的独立扩容和缩容能力,以及存储资源与计算资源在弹性扩缩容环境下的自由组合能力。从本质而言,GaussDB 云数据库系统提供多租户(Multi-tenant)和扩缩容(Elasticity)的组合能力。

2.3.2.1 多租户存储计算共享架构

        单个应用服务独立部署转向共享服务,对企业内部数据库系统的运维产生较大的变革,并有效降低其运维成本。

        如下图所示,数据库系统从孤立的独立部署转向计算与存储共享的部署形态,在实现计算与存储共享的同时实现存储资源的独立扩缩容,以及计算资源独立的扩缩容。当云部署的数据库系统能够提供独立的存储、计算扩缩容能力后,数据系统需要被迁移的概率将被大幅度降低,由此可以提升数据库系统的业务连续性(BusinessContinuity),系统比较容易实现在运行过程中存储资源的扩缩容,以及计算资源的扩缩容。

图11 多租户数据库系统部署形态

2.3.2.2 三层逻辑架构实现存储、计算独立扩缩容

        为了有效实现云数据库系统在存储资源、计算资源的独立扩缩容,需要实现计算与存储的解耦,以及各自的扩缩容能力。

        如下图所示,为了实现GaussDB云数据库系统在存储和计算方面的弹性,现将整个数据库系统分为3层,分别是弹性存储层、弹性事务处理层及无状态SQL 执行层。GaussDB云数据可以在事务处理层实现横向扩展,以保证满足大中型企业对数据库系统的不同需求。无状态的SQL执行层,可以实现对不同客户端连接请求数进行扩展的能力。

图12 GaussDB云数据库系统的分层架构

        GaussDB虽然实现了在数据库系统3个层次上的不同可扩展能力,但是不要以为这些组件是部署在不同的物理机器上。相反的,为了更好地提供性能,这3个层次的组件通常在部署的时候,具有很强的相关性,需要尽可能地联合部署(尽量部署在一台物理机上或一个交换机内),以降低网络时延带来的开销。

2.3.2.3 云数据库的克隆与复制支持

        将企业的数据库系统搬到云系统之上,可以提供更加便利的数据库系统管理功能,以满足企业对业务的测试、新业务的构建等不同需求,加速业务上线的速度。

        由于云数据库系统实现多个数据库系统之间数据的共享(即在一个存储池中,存储大量的数据库)。因此,可以实现对这些数据库高效的复制、克隆等功能。比如,某公司可能需要基于现有数据库系统的当前数据,开发一个新的应用。传统的做法是,为了测试应开发的应用不影响到现有的线上应用,公司通常会构建一个新的数据库系统,并从当前线上系统导出一份最新的数据,将这份新的数据导入另外一个数据库系统中(比如刚创建的数据库系统实例),并在该数据库系统开发、测试新的应用。

        当这些数据库系统共同部署在云数据库系统中时,可以实现数据库系统的克隆(包括数据与系统)和复制(仅数据),比如使用COW 机制(对于持久化存储的Copyon-Write机制)可以实现对于数据库数据的快速克隆(仅克隆了元数据,数据库数据并未复制)。通过COW 机制,构建在克隆数据库上的业务可以直接修改克隆的数据库系统中的数据。

        如下图所示,云数据库系统可以对生产数据库系统进行克隆、复制等操作,对于克隆、复制出来的数据库系统可以用于非生产系统,并用于开发、测试流程或是参与到基准测试中。需要说明的是,用户非生产系统的数据库系统保持了和生产系统当前一致的数据,同时生产系统中更新的一部分数据也可以实时同步到非生产数据库系统中,进而保持这两部分数据之间的一致性。

图13 GaussDB云数据库系统的数据库克隆与复制

        通过上述分析,GaussDB云数据库系统通过分层,实现了在存储层和计算层的弹性以及这两者的任意组合,能够较好地适应大中型企业对云数据库系统的需求。另外,GaussDB云数据库系统在此基础上又进一步实现了对现有数据库系统的高效克隆、复制,以满足中大型企业提升业务演进的速度和节奏。

2.4 GaussDB多模数据库架构

        从字面意思来理解,多模数据库系统主要用于实现对多种模型数据的管理与处理。它包括3个层面的内容:

• 多模数据的存储: 一个统一的多模数据库系统需要提供多种数据模型,包括关系、时序、流、图、空间等的存储
• 多模数据的处理: 一个统一的多模数据库系统需要提供多种数据库模型,包括关系、时序、流、图、空间等的处理能力。
• 多模数据之间的相关转换: 大多数情况下,客户的数据产生源只有一个,即数据产生源的数据模型是单一的,但是后续处理中可能需要使用多种数据库模型来表征物理世界,进而进行数据处理,或者需要通过多种模型之间相互协作来完成单一任务,因此不同模型之间的数据转换也是极为重要的。

2.4.1 设计思想与目标客户

        多模数据库系统的设计与实现,主要是为了简化客户对数据管理、数据处理的复杂度,以及降低整体系统运维的复杂度。为此,在数据库系统之上提供统一的多模数据管理、处理能力,以及统一运维能力是多模数据库系统核心设计思想。经过近两年的设计与开发,我们总结出客户的需求,客户可以分成如下两大类,而不同的类别的客户将影响到整个多模数据库系统的架构。

• 侧重多模数据一致性的客户: 这类客户通常有比较单一的数据产生源,并以关系数据为主,重要关键性业务是强调数据之间的一致性,如银行类客户、政府类客户。在构建多模数据库系统时,需要重点考虑多模数据之间的一致性,以及多模数据之间的融合处理。
• 侧重多模极致性能的客户: 这类客户的需求通常无法通过简单的多模数据融合来达成。在他们苛刻的条件下,通常需要极致地优化性能,才能满足他们的需求。

2.4.2 面向数据强一致的多模数据库系统架构

        GaussDB用户除能使用关系数据库外,还有使用图数据库、时序等多模引擎的能力。如公共安全场景下,用户会将MPPDB(Massively Parallel Processing DataBase,大规模并行处理数据库)的数据,导出到图数据库中,使用图引擎提供的图遍历算法,查找同航班、同乘火车等关系。在类似应用场景下,存在数据转换性能低,使用多套系统维护和开发成本高,数据导出安全性差等问题。引入多模数据库统一框架[Multi-ModelDatabase (MMDB) Uniform Framework],为用户提供关系数据库、图数据库、时序数据库等多模数据库统一数据访问和维护接口,减少运维和应用开发人员的学习和使用成本,提升数据使用安全性(数据无须在多个系统之间进行切换,减少了数据在网络上暴露的时间),如下图所示。

图14 多模数据库逻辑架构图[Multi-Model Database (MMDB) Uniform Framework]

2.4.2.1 系统逻辑架构

        多模数据库统一框架基于GaussDB开发,通过类似领养(Linked)机制,快速扩展图、时序数据库引擎,对外提供统一的DML、DDL、DCL、Utilities、GUI访问接口。运维和应用开发人员可以将扩展的多模数据库与GaussDB无缝衔接起来,当成一套系统,统一管理与运维通过统一接口使用扩展引擎提供的能力,减少对新的数据库引擎的学习和使用成本。具体介绍如下。

• 扩展引擎(Extension Engine)包括图引擎、时序引擎、空间引擎,扩展采用统一机制、模块化设计,并提供类似领养机制,具有扩展快速、对原系统无影响的优点。
• 统一(Uniform)DML提供关系数据库SQL、图数据库图遍历语言(Gremlin)、时序函数和操作等多语言的数据操作能力。用户可以使用统一的ODBC、JDBC、GUI接口访问MPPDB及扩展引擎。
• 统一DDL、DCL、Utilities均使用存储过程,为各扩展引擎维护专属的虚拟系统表(Pseudo Catalog),减少对MPPDB的影响和依赖。
• 统一DDL为扩展引擎提供统一数据定义能力,包括扩展引擎创建、删除,扩展引擎对象的创建、销毁[如上图所示图引擎的图(graph)、顶点(vertex)、边(edge)的创建和删除]等DDL能力。
• 统一DCL为扩展引擎提供统一数据控制能力,包括统一权限(Grant、Revoke)管理,性能统计(Analyze)能力。
• 统一Utilities提供备份恢复、安装卸载、集群管理等功能。
• 统一GUI在高斯Data Studio IDE基础上,扩展了对图数据库、时序数据库的支持,提供扩展引擎的基本数据访问接口及管理接口(备份、恢复等)。设计时尽量保持Data Studio原有系统设计及显示结构,减少对原有Data Studio的改动量。

        在上图的多模数据库系统的逻辑架构中,除了统一的多模框架外,该系统架构使用了统一的数据存储,即关系型存储。据统计,当前大量客户的数据产生源主要包括两大类: ①关系型交易数据系统; ②传感器(周期性地产生比较规则的数据)。分布式关系数据库系统实现数据的统一存储与处理,可以大幅度简化客户的数据处理,最终实现数据的强一致。

        为了简化用户对数据的管理与处理,我们在数据统一存储(即关系型存储)的基础上提供了多类数据处理引擎,包括图引擎、时序引擎、空间引擎等,不仅可以提高对多类数据模型的处理效率,同时也提供了多类数据处理引擎的处理语言。比如,对于图引擎,提供了Gremlin图处理语言的支持; 对于时序引擎,提供了业界标准的时序处理语言。

        多模数据库系统中多模数据模型的任意组合。为了适应不同用户对不同类型数据处理的需求,GaussDB多模数据库系统提供了多种模型之间的任意组合。在整体架构上,将引擎的元数据独立出来,以实现任意时刻的启动和关闭新的多模引擎。

2.4.2.2 系统物理架构

        多模数据库是处理包含图、时序等多种数据模型的统一的数据库。下图给出了多模数据库的物理设计架构图。多模数据库提供统一的DDL和DCL管理,用户可以方便地把外部引擎交给多模数据库进行管理。

图15 GaussDB多模数据库的物理设计架构图

        多模数据库DML采用UDF(User Defined Function,用户自定义函数)的方式,提供统一的GUI、ODBC、JDBC等外部接口,输入相应的UDF进行对外部数据的查询分析。多模数据库接收到查询请求后,发送给对应的外部引擎执行,并将执行结果返回,借助GaussDB原有的方式呈现给用户。

        多模数据库的系统表采用虚拟系统表(Pseudo Catalog)的方式管理。虚拟系统表都是用户表。这样,用户可以方便地添加和删除多模的能力,对MPPDB的影响减到最小。

        多模数据库在GaussDB 基础上进行设计。GaussDB 引入多模框架后,需要在GaussDB内部进行扩展,用来适配多模数据的执行和管理流程。这里的扩展指的是GaussDB内部针对多模引擎所做的适配。它既可以是功能上的,包括多模数据对象和关系数据对象的相互依赖关系,对异常处理、事务管理所做的适配,还有针对多模数据的执行流程在GaussDB内部所做的适配工作;又可以是性能上的,例如优化器等组件上提供对多模引擎的支持。

        公共模块(Common Envelope)介于这些扩展和外部引擎之间,关键组件———公共模块封装(Common Envelope Wrapper)打包提供了GaussDB扩展针对不同引擎的具体实现。也可以把这部分内容叫作外部引擎封装(Foreign Engine Wrapper)。即针对不同的引擎,可以通过外部引擎封装打包不同的实现过程。

        此外多模数据库还提供其他统一框架管理,包括连接管理、轻量解析(ShallowParse)和多模缓存管理等。

2.4.2.3 面向极致性能的多模数据库系统架构

        面向极致性能的场景,如极端的互联网场景,上述多模数据系统可能无法满足需求。如果需要处理的数据量,或者需要处理的响应时间包含有极致的要求,统一的关系存储可能无法满足要求。在这类业务场景下,通常需要面向特性数据模型的原生数据存取模型,进而加速数据的存取与处理,面向极致性能的多模数据库系统架构如下图所示。

图16 面向极致性能的多模数据库系统架构

 参考链接

【文章汇总】GaussTech技术专栏-云社区-华为云

【酷哥说库】系列课程汇总-云社区-华为云

【GaussTech】分布式数据库技术的演进和发展方向-云社区-华为云

GaussDB系列数据库简介_gaussdb官网-CSDN博客

GaussDB社区_华为云GaussDB_开发者社区_华为云

高斯数据库GaussDB详解

GaussDB(DWS)介绍-CSDN博客

gaussdb简介

将GaussDB主备版同步到Oracle_数据复制服务 DRS_华为云

Oracle迁移至GaussDB最佳实践

本地Oracle同步到GaussDB分布式版_数据复制服务 DRS_华为云

GaussDB架构（上）_高斯db用了多久-CSDN博客

GaussDB架构（下）_数据库_Gauss松鼠会-华为开发者空间

GaussDB经验总结

openGauss核心技术

openGauss内核分析

一文读懂GaussDB的六大关键技术特性-云社区-华为云

【openGauss数据库内核分析系列】：SQL by pass & 经典执行器_opengauss内核-CSDN博客

【酷哥说库】系列课程汇总-云社区-华为云

postgres-xc介绍-CSDN博客

LLVM技术在GaussDB等数据库中的应用_数据库_Gauss松鼠会-华为开发者空间