摘要：GaussDB(for MySQL) 是华为自研云原生数据库，具备高性能，高扩大，高牢靠的特点，齐全兼容 MySQL 协定，自研架构和敌对的生态兼容性，能够同时满足数据库管理员、利用开发者、CTO 的运维、应用和业务倒退需要，本次次要介绍 GaussDB(for MySQL) 在云原生技术方向上遇到的挑战和将来的倒退演进门路。
在 2023 云数据库技术沙龙“MySQL x ClickHouse”专场上，华为云数据库高级产品经理周家恩，为大家分享一下《GaussDB(for MySQL) 云原生数据库技术演进和挑战》的一些技术内容。
周家恩，华为云数据库高级产品经理，10 年以上数据库技术运维，产品治理教训，先后在多家 TOP 云厂商任职产品经理，相熟 MySQL，SQL Server 等多款数据库治理，保护以及商业经营工作，现任华为云数据库高级产品经理，负责原生数据库 GaussDB(for MySQL) 产品治理和设计，经营工作。
本文内容依据演讲录音以及 PPT 整顿而成。
大家好，先让我自我介绍一下。目前我在华云数据库团队负责数据库产品经理，次要负责 MySQL 畛域的产品布局。明天我带来的主题是《GaussDB(for MySQL) 云原生技术的演进和挑战》。
让咱们先来看一下华为数据库的倒退历程。可能在许多人的眼中，华为是以硬件起家的公司。但实际上，华为数据库的倒退曾经开始了十几年，起步十分早。在云这块的话有几个阶段，咱们次要分成两条线：开源和云原生数据库。
开源方面，咱们波及到的是 RDS 和 MySQL。而对于云托管，咱们早在 2014 年 15 年左右就开始了外部业务的应用。此外，咱们还推出了云原生数据库，其中包含云原生 MySQL。亚马逊在 2014 年推出后，很多云厂商都一直地在借鉴和学习。在 2018 年和 2019 年，咱们公布了第一个商用版本。
在咱们看来，云原生数据库与存储的可用性、可靠性和性能密切相关。华为的企业级存储在中国市场领有十分不错的市场占有率，因而咱们将云原生数据库与华为的企业级存储严密交融。随着架构和技术的一直演进，咱们在 2019 年推出的商用版本，这就是咱们华为数据库倒退的历程。
让咱们来理解一下 GaussDB(for MySQL) 的零碎架构。GaussDB(for MySQL) 是一款基于存算拆散架构的云原生数据库，齐全兼容 MySQL 协定，并由华为自主研发的分布式存储系统作为底层撑持。它采纳 active 架构，相比传统开源架构，不须要备库进行数据同步，从而节俭了用户的老本。最要害的一点是，GaussDB(for MySQL) 采纳日志即数据架构，这一架构最早由亚马逊的 Aurora 推出。该架构的劣势在于优化了 MySQL 事务提交门路，从而显著晋升了整个事务提交的性能。
让咱们先来理解一下咱们在性能方面做了哪些工作。通常来说，云原生数据库在性能方面当先于传统架构。咱们通过实测发现，在写入性能方面，咱们的性能是开源架构的七倍。这次要归功于咱们的架构设计。
咱们采纳了存算拆散架构，不同厂商的设计会有所不同，但咱们的设计与亚马逊的 Aurora 比拟类似，能够说华为的架构与亚马逊最靠近。咱们采纳了日志即数据架构，即在整个事务写入时，咱们会间接进行 REDO 落盘即事务提交，不须要再从计算节点刷脏页到磁盘，从而大幅缩小了整个事务提交的网络负载和开销。因而，咱们的写入性能比开源架构和没有采纳这种架构的厂商都要高。
本次流动中咱们次要探讨 MySQL x ClickHouse，在 TPCH 畛域，咱们也做了很多优化工作，并开发了并行查问技术，从而在性能方面获得了很大的晋升。
上面看一下咱们在性能这块做了一些优化。
就并行查问而言，目前咱们在 TPCH 的 22 个 SQL 中的整体性能晋升能够达到 26 倍。华为在并行查问方面所做的一些工作与其余厂商也稍有不同。
就目前在云原生数据库畛域比拟大的几家友商来说，例如 Aurora，在并行查问这个方面，它是通过将算子下推到存储引擎上来实现的。而亚马逊并不是在 SQL 引擎这一层面进行并行操作，它次要是充分利用了其分布式存储来晋升性能。而像国内其余友商，则次要是在 SQL 引擎层面进行并行操作。
其实咱们做了两个方面的工作。一方面，在 SQL 引擎层面，咱们实现了并行操作，就像上一页所讲的那样。另一方面，咱们还实现了 NDP 算子下推，充分利用了分布式存储的性能，将底层存储资源充分利用起来。咱们对简单的算子、Filter、Projection、谓词包含比拟运算等进行了下推优化，同时也对疾速列和虚构列进行了下推。因而，在简单查问方面，咱们称之为“双轮驱动”，这也是咱们与其余厂商不同的中央。接下来，看下理论的性能体现。
这个就是开启 NDP 在 TPCH 场景下的一个性能体现。开启当前，最高场景是能够就是计算到网络之间的开销。开源的 MySQL 在进行大的简单查问时，咱们须要将数据从磁盘传输到计算层进行计算，会有大量网络开销，而通过算子下推技术，TPCH 解决多个 SQL 时，咱们看到网络开销的最高节俭率超过 90 倍。在性能方面，咱们测试了 NDP+PQ 场景，该技术品牌被称为 NDPQ。性能体现最高晋升高达 30 倍以上。
在可用性方面，咱们的 DFV 反对跨 AZ 能力。目前，华为云国内的主力 region 包含上海、北京、广州、贵阳、乌兰察布等都反对 3AZ 部署。将来，3AZ 部署也将成为华为云 GaussDB(for MySQL) 的默认架构。往年咱们正在开明的节点中，包含香港、曼谷以及拉美、中东等地区。在欧洲，咱们与德国电信和法国电信单干，推动 GaussDB(for MySQL) 全球化过程。咱们的跨 AZ 能力能够实现 RPO=0，保证数据的高可靠性。
对于扩展性，咱们晓得在云上应用 MySQL 数据库，它更适宜互联网业务，尤其是互联网、游戏和电商等用户。当然，当初政企客户也越来越多地上云，咱们也为此做了节点的主动扩大，以满足更多不同类型客户的需要。目前，我集体感觉当初云有一个十分重要的的趋势倒退，其中一个要害的趋势是 HTAP。另外，Serverless 也是一个重要的趋势。咱们能够看到，像亚马逊去年的 invent 大会上最外围的公布之一，就是所有数据库开始向是 Serverless 化发展。
在云上除非技术实力特地强之外，用户最关注的问题就是老本。因而，咱们提供了一种相似于 Serverless 的服务，反对按需主动弹性扩大。这是咱们晚期推出的一个雏形，其中包含主动弹性扩大周期和按需模式。因为采纳了存算拆散架构，加节点的弹性过程十分疾速，个别只须要五到十分钟即可实现。因而，它的速度比传统的 MySQL 快得多。传统的 MySQL 在数据量一直减少时，进行规格变更和加节点所需的工夫十分长。
在备份方面，咱们的存储采纳基于 AppendOnly 模式的 DFV 存储。咱们实现了秒级快照，这是咱们本人开发的快照零碎。咱们进行了测算，发现大概 1TB 的数据备份复原只须要三四十分钟即可实现。
咱们还将在今年年底推出 backtrack 性能，该性能基于存储的多版本个性，用户能够在抉择的工夫点范畴内进行回溯操作，往前或往后。咱们能够将 1TB 数据这个级别的回溯工夫管制在五分钟以内。
再看数据库代理服务，咱们目前反对用户按需购买服务。默认状况下，咱们不提供代理服务。如果用户有需要，能够按需购买读写拆散服务，无需对其业务进行任何改变即可主动实现读写拆散。
咱们往年对读写拆散进行了大量的优化，其中包含基于负载平衡模式的反对，咱们还依据业务特色，反对用户抉择最终一致性、会话一致性和全局一致性三种一致性级别。
咱们的代理服务反对只读模式和读写模式。如果用户须要在剖析型业务和交易型业务之间进行物理隔离，能够抉择只读模式。在只读模式下，代理服务会为用户创立不同的只读节点，从而实现对剖析业务和交易业务的物理隔离。
接下来介绍咱们的 HTAP 只读剖析节点。这是咱们在 HTAP 畛域中一直推动的一步。正如我之前所述，咱们在简单查问方面采纳了并行查问和算子下推等技术。然而这些还不足以满足所有用户的需要，因为这 2 个技术实质上仍在同一份数据上进行操作，也就是说还是在整个一套零碎外面。
因为大家都晓得，在做 TPCH 这样的场景时，对整个资源的耗费是不可控的。一个剖析业务可能会影响到交易型业务。为了解决这个问题，咱们开发了只读剖析节点，它基于 ClickHouse 实现。通过 CDC 模式，咱们能够将用户交易数据从 GaussDB(for MySQL) 同步到 ClickHouse。正如之前的嘉宾所介绍的，咱们也是采纳了基于 binlog 的计划。
咱们目前还处于公测阶段，次要服务于华为外部的终端消费者，例如华为手机、手环和静止衰弱等业务。这些业务的一部分剖析业务曾经迁徙至咱们的只读剖析节点上。
对于并行创立索引，咱们都晓得社区版的 MySQL 在创立索引时是单线程操作，无奈实现多线程。因而，如果要创立一个较大的索引，耗时会十分高。为了解决这个问题，咱们开发了多线程的索引创立性能，多线程被设计用于从存储读取数据、排序以及创立索引等操作。通过测试，该性能相比于开源版本的 MySQL，能够晋升性能六到七倍。
在咱们后续产品的演进中，Serverless 将是一个十分要害的方向。咱们打算在往年上半年（五六月份）进行 Serverless 的公测，下半年则会正式商用。在 Serverless 畛域，咱们曾经做了很多摸索。目前业内最为杰出的 Serverless 产品是亚马逊的 Serverless V2。尽管亚马逊在最后推出的 Serverless V1 曾经引起了不少关注，但它仍存在某些局限性，例如扩缩的粒度和速度可能不够现实。然而随着 Serverless V2 的推出，它的扩缩粒度能够达到 0.5 ACU，而且端到端的感知速度只需十秒钟。因而，过后的亚马逊 Serverless V2 能够说是引领了整个云原生数据库 Serverless 的发展趋势。
咱们还在技术方面进行了很多翻新。其中，咱们实现了疾速弹性的缓冲池（buffer pool），并在内核层面对其进行了减速。通过这一技术，咱们能够实现毫秒级的扩大，从而在端到端的运行过程中，通过外部环境测试后，可在大概十秒钟内（甚至可能更快，大概八秒左右）实现。
咱们还摸索了一些技术，例如 ALT 利用通明迁徙。在 Serverless 畛域，跨机操作是一个关键点。在单机内，咱们能够绝对简略地实现弹性伸缩，然而在云上，咱们须要思考如何跨多台物理机经营，如何扩充资源池规模。这带来的问题是资源池水位可能会比拟高，在扩大过程中可能会呈现资源有余的状况，这时咱们须要跨机操作，因而保障迁徙的平稳性和不中断就显得尤为重要。咱们实现了 ALT 利用通明迁徙技术，通过事务状态放弃等形式，实现了安稳迁徙。
在 Serverless 畛域，咱们曾经实现了按需付费的存储，计算层打算在往年五六月份推出，而 Serverless 代理层预计会在今年年底推出。
最初再看一下咱们的几个案例，其中第一个种子用户是国内比拟大的保险公司。他之前应用的是 Oracle，但因为国产化的需要和去 O 的需要，他们抉择了咱们的服务。因为咱们的服务能够部署在私有云上，咱们通过一些专家服务和相干工具对该公司业务进行评估，并将其迁徙到 GaussDB(for MySQL)。迁徙实现后，该公司的 TCO 升高了 50%。
咱们的另一个案例是华为终端。整个业务规模十分大，涵盖了华为整个手机业务、汽车业务以及利用商店等实例，实例数量能够达到十分大的规模。以前，因为线下的自建数据库存在许多痛点，他们有一个宏大的 DBA 团队来保护。常常面临可用性和运维相干的问题，以及如果产生切换，可能会面临数据失落的状况。
迁徙到 GaussDB(for MySQL) 后，他们面临的问题像数据失落就曾经不存在了。此外，咱们一直演进，扩大了主动弹性伸缩等个性。让用户的老本升高了 40% 左右。同时，他们以前应用了商业的剖析型数据库软件，也开始逐渐应用咱们的 HTAP 剖析只读节点，这进一步升高了整体的老本。
好，那我明天分享就到这里，谢谢大家。
本次大会围绕“技术进化，让数据更智能”为主题，汇聚字节跳动、阿里云、玖章算术、华为云、腾讯云、百度的 6 位数据库领域专家，深刻 MySQL x ClickHouse 的实践经验和技术趋势，联合企业级的实在场景落地案例，与宽广技术爱好者一起交换分享。