乐趣区

关于数据库:翻过三座大山MatrixOne从-NewSQL-到-HTAP-分布式架构演进

导读

最近的几年中,HTAP 数据库成为了一个时尚词汇,言必称 HTAP 也成了很多数据库畛域从业者的风潮。如何打造一款 HTAP 数据库,从架构层面登程,去应答将来的变动,拥抱变动,也是很多数据库公司所始终在摸索的。

MatrixOne 是矩阵起源(MatrixOrigin)开源的一款超交融 HTAP 云原生数据库,与业内诸多数据库产品十分不同的点是,MatrixOne 的自研之路是从第一行代码开始的。MO 的指标是打造一款极简、高扩展性、高灵活性、高性价比的全新数据库。

在过来的两年里,MatrixOne 经验了一次架构的演进,更具备试验性质的旧架构到面向未来的新架构,成为了诸多数据库开发工程师与运维工程师的关注点,他们经验怎么的架构演进,这两头又有哪些值得借鉴的内容,将在本文中为大家一一揭晓。

上面是本文目录概览:
1. 晚期架构的千层糕
2. 三座大山,推倒重来
3. 新生后的 MatrixOne
4. 积跬步以至千里
5. 复盘播种
6. 总结


Part 1 晚期架构的千层糕

MatrixOne 作为一款开源分布式架构的数据库,已有靠近 2 年的生命历程。我置信有很多社区老用户,会对晚期架构时 SSB 测试的高性能留有印象。而到了 0.5 版本公布之后,性能忽然就大幅下滑。过后就有敌人问我,怎么还越做越回去了?我对他说,有个大动作,整个架构做了一个大规模的降级。

此时此刻,我觉得很有必要,对整个架构的演进降级,做一个残缺的论述。

如何界定 MatrixOne 的晚期架构?明确地说,是指 MatrixOne 从 0.1 到 0.4 版本的架构,也是在 2022 年上半年之前,在各类推送中呈现的那个架构。与其说这是一个架构,更不如说,这是一场试验,通过一个架构,去摸索出各种架构的有余,找到真正适宜于与原生的 HTAP 分布式架构。

这个试验的旧架构,有两个显著的特色:NewSQL 与 MPP。前者是基于 Google 当年的几篇经典论文所衍生出的,也是明天很多数据库产品的总思路。后者 MPP,顾名思义,大规模并行处理,并行计算是它们的显著特点。落地到 MatrixOne 的晚期架构,又有了更具体的含意。

NewSQL

  • 分布式架构:多节点的分布式数据库服务器,每一台服务器既蕴含了计算资源,又有各自的存储节点,解决了传统单机数据库伸缩性和高可用问题。
  • 多引擎:数据库服务器中可能存在多个存储引擎,不同的引擎个性不同,负责不同的场景。

MPP

  • 并行计算:将工作并行地扩散到多个服务器和节点上,在每个节点上计算实现后,将各自局部的后果汇总在一起失去最终的后果。

1.1 晚期架构详解

进一步拆解,将视角拉到 MatrixOne Server 外部,它又有着多个模块,分工协同,实现整个分布式数据库的性能。一共分为 5 个局部,前端、计算层、分布式框架、存储层、元数据层。五个局部各自的性能与个性又各有不同。
SQL Frontend
亦称 SQL 前端,是间接解决 SQL 语句的局部,它提供了如下性能:

  • 提供 MySQL 兼容协定,确保 MySQL 的各类协定可能被 MatrixOne 接管;
  • 兼容 MySQL 的语法,对接管的 SQL 做合乎 MySQL 的语法判断。

Query Parser
是 MatrixOne 中对语法解析的功能模块,它提供了如下性能:

  • SQL 解析,对前端的 SQL 并转化形象语法树;
  • 方言反对,提供反对多种 SQL 方言根底。

MPP SQL Execution
是实现 MPP 的 SQL 执行器,它提供了如下性能:

  • SQL 减速,对 SQL 计算引擎的一些根底操作的向量化减速,局部操作采纳汇编改写做减速;
  • Plan 构建,应用独有的因子化减速能力做 SQL 的 Plan 构建。

分布式框架
晚期 MatrixOne 的分布式框架叫做 MatrixCube,同样是一个开源我的项目,它具备了如下组件与性能:

  • 提供高可用、多正本、强统一与主动负载平衡;
  • 提供分布式事务的反对能力(WIP);
  • 提供基于 Raft 的正本调度机制,该调度器在代码中称为 Prophet。

存储层
晚期的 MatrixOne 存储层是一个领有多个引擎的架构,多种存储引擎相互分工协作,共同完成 HTAP 数据库性能:

  • AOE 引擎,Append Only Engine,这是一个 Append Only 的列存引擎,不反对事务;
  • TPE 引擎,Transaction Processing Engine,用于保留元数据 Catalog;
  • TAE 引擎,Transactional Analytical Engine,基于列存的 HTAP 引擎,会提供残缺 ACID 能力及弱小的 OLAP 能力。

元数据层是一个在晚期 MatrixOne 架构中被每个其余模块都频繁调用的内容,保留在 TPE 引擎中,提供了全局的元数据的保留与读取,是一个频繁应用的模块。

1.2 晚期架构,何以有余?

作为一个晚期的架构,更多的是承载了研发团队晚期的摸索和钻研,通过试验架构,逐渐摸索出一条面向未来的架构。随着开发进度的一直推动,毫无意外地,旧架构的问题开始凸显进去,并且随着性能与性能的晋升,愈发成为后续倒退的枷锁,集中在三个方面暴发:

拓展性

  • Share nothing 架构,每扩大 1 单位节点,需同时扩大存算资源;
  • 每份数据至多要保留 3 正本,从扩大节点到实现,工夫更久.

性能

  • Raft 协定所蕴含的 leader 角色,容易造成热点;
  • 在性能较差的存储下,数据库整体性能降落会超过预期;
  • 多种引擎各自用处不同,性能各异,无奈有效应对 HTAP 场景。

老本

  • 数据保留 3 正本,随节点规模,老本一直攀升,云上版本更甚;
  • 只有高配存储能力施展数据库的预期性能。

这三大难题不得不令 MatrixOne 团队去思考,到底什么样的架构能力满足将来 HTAP 的需要,让云用户与私有化客户,获得最佳产品体验与最佳实际。如同很多破而后立的故事的开始,此时此刻恰如彼时彼刻,由 CTO 田丰博士引领,MatrixOne 团队开始了架构的降级之路。


Part 2 三座大山,推倒重来

三大难题是旧的试验架构的表象,如果仅仅依据表象去解决问题,无疑只能做到知其然而不知其所以然。更深层次的起因,依然须要去被开掘与确认,通过 MatirxOne 研发团队的重复的假如与论证后,旧架构有余的根因,归结为三个大问题,这是压在 MatrixOne 之上的三座大山,如同幽灵个别,在每个 MOer 的头上回旋

2.1 分布式框架

MatrixCube 作为过后的分布式框架,提供了多正本存储模式,每一份数据都保留 3 正本并且以分片(shard)模式保留,使得存储的老本飙升。

而基于 Raft 选举的 Leader 节点,频繁成为了热点,各类操作都须要通过 Leader 节点进行散发,在极其业务场景下,Leader 节点的负载会数倍于一般节点

2.2 引擎泛滥

晚期的 MatrixOne 内置了三种存储引擎,三个引擎之间代码复用率较低,使得对性能的保护须要投入更多人力。

而基于因子化算法的 Plan 构建形式过于激进和形象,在计算组外部对其齐全了解的程序员数量无限,往往增加性能时仍旧须要主开一人实现,新性能增加迟缓。

2.3 资源分配

旧架构采纳了存算不拆散的架构,这个架构导致了扩展性较差。每扩大一个单位的计算节点必须同步扩大存储资源。

因为存储采纳了 shard 分片,使得在 shard 较大时影响了 OLTP 的性能,在 shard 较小时,又会影响 OLAP 性能。
在找到了三座大山之后,接下来要做的事件就是一一扳倒它们,田丰博士联合 MatrixOne 的产品愿景以及将来的技术趋势,对于试验架构进行了总结,并提出了 MatrixOne 独有的架构构想,从整个架构的现状来看,要分三步走:

  • 第一步,将旧架构 share nothing 的框架破除,实现更灵便的解耦;
  • 第二步,将多种引擎合二归一,实现外部引擎的大一统;
  • 第三部,重构计算引擎,留有足够的空间给将来的产品倒退。

Part 3 新生后的 MatrixOne

新架构通过解耦,最终实现了三个各自独立的层级,每个层级有本人的对象单元与分工,不同类型的节点能够灵便伸缩,不再受到其余层的制约:

  • 计算层,以计算节点 Compute Node 为单位,实现了计算和事务处理的 Serverless 化,又有本人的 Cache,能够实现任意重启与扩缩容;
  • 事务层,以数据库节点 Database Node 为与日志节点 Log Service 为单位,提供残缺的日志服务以及元数据信息,内置 Logtail 用于保留最近数据;
  • 存储层,全量数据保留在以 S3 为代表的对象存储中,实现了低成本的无线伸缩存储形式,以 File Service 命名的对立文件操作服务,实现了不同节点对底层存储的无感知操作。

在确定了以 TAE 作为惟一存储引擎之后,对交融后的 TAE 引擎又做了诸多设计上的调整,才有了起初交融后的 TAE 存储引擎。实现了繁多引擎实现所有数据库存储行为的指标,并且具备了如下劣势:

  • 列存治理,对立的列存与压缩,对于 OLAP 业务有着先天的性能劣势;
  • 事务处理,共享日志与 DN 节点共同完成对计算节点的事务反对;
  • 冷热拆散,应用 File Service 以 S3 对象存储作为指标,每个计算节点都有本人的 Cache。

屡次运行测试,得出置信度较高的后果:

晚期的计算引擎中,兼容 MySQL 的大指标没有变动,然而对于节点调度、执行打算、SQL 能力又有着更高的要求。重构后的高性能计算引擎,既具备了试验架构中计算引擎的 MPP,又补救了过来的诸多有余:

  • 兼容 MySQL,既有对 MySQL 协定的反对,又蕴含了对 MySQL 语法的反对;
  • 交融引擎,基于 DAG 从新构建执行打算,能够同时执行 TP 和 AP;
  • 节点调度,将来可反对自适应节点内和节点间调度,同时满足并发和并行执行;
  • 欠缺 SQL 能力,反对子查问、窗口函数、CTE、Spill 内存溢出解决等。

Part 4 三座大山,推倒重来

回顾历时数月的架构降级之路,充斥了各种辛酸和苦楚。无论思考的如许充沛,在理论开发中,总会遇到各种各样意想不到的问题呈现,尤其是在一些关键问题上的艰难,让研发团队从开始的束手无策,到偶然的灵光乍现,再到很前面的零之曙光,走向最终的拂晓时刻。个中三昧,显而易见。

这些难题中,次要围绕在存储、事务、负载隔离与资源配比几个方面。

4.1 寻找更适合的存储

在意识到三正本存储带来的问题后,如何寻找一个新的存储适配新架构,成为了过后一大难题,而这个新的存储必须满足两个外围需要,低成本与冷热数据拆散。

在对市面上的诸多存储进行了调研以及试验之后,AWS S3 成为了最终的抉择。繁多正本,自带的冷热数据拆散。

4.2 事务分工的调整

最后的新架构中,计算节点 CN 与数据库节点 DN 之间的分工是 CN 负责计算,计算结果推给 DN,由 DN 实现事务。随着开发进度的一直推动,这个分工开始呈现了问题,DN 对事务的解决能力成为整个零碎的瓶颈。因而,对于 CN 和 DN 的分工,必须做从新定义:

  • CN 负责所有的计算以及事务逻辑,DN 负责保留元数据信息、日志信息以及事务裁决,DN 不再成为瓶颈;
  • 在日志中引入 Logtail 对象,用于保留最近日志中的关联数据,定期将 Logtail 的数据写入 S3 中,CN 扩容能够实时将 Logtail 数据同步至 Cache,实现了局部数据共享;
  • 为事务大小设置阈值,超过阈值下限的事务间接写 S3,日志只保留记录写入记录,未超过阈值的事务持续由 DN 写入,极大减少了吞吐量。

4.3 实现 HTAP 的工作负载隔离

作为 HTAP 数据库,如何实现不同类型的工作负载隔离,是一个必须解决的问题。在实现了对旧的试验架构的灵便解耦之后,工作负载的隔离也得以实现:

  • 服务器级别的隔离,硬件资源富余的状况下,各个组件别离在不同的物理机运行,接入同一个对象存储;
  • 容器级别的隔离,硬件资源无限的状况下,利用所有节点无状态的个性,以容器作为各个节点的隔离伎俩。

4.4 实现资源配比的灵便调整

作为 HTAP 数据库,日常业务中,不同业务场景的比例是在动态变化中,对于资源的配比也有着更高的要求,而旧架构下的资源分配模式注定无奈实现灵便调整,须要对各个节点实现更加精细化的治理,蕴含但不限于:

  • CN 节点的分工,容许用户对 CN 进行划分,用于 TP 或 AP 业务,其中某项业务资源呈现瓶颈之后,对 CN 进行程度扩容;
  • 在不类业务的 CN 组之间,动静判断各组的负载状况,以后两类业务的负载差别较大时,能够主动将闲置资源分配至忙碌组内;
  • 通过租户(account)的逻辑概念,实现逻辑资源的齐全隔离,不同的租户能够以独享或共享的形式应用指定的 CN 资源。

Part 5 复盘播种

在诸多问题得以解决的背地,是泛滥 MOer 一次次发动的攻坚,在阵痛之后,也播种了很多过来未曾涉足过的常识与教训。这些不仅仅是解决问题的积攒,同样也为今后 MatrixOne 的开发积攒了一比贵重的财产。

为此我从解耦之后的三层架构角度,对相干几位共事做了访谈,在聆听了他们对问题的回顾与思考之后,做出了如下的反馈:

计算层

  • 了解 SQL 的执行,通过重构 Plan,对于 SQL 语法的解析、执行打算以及 SQL 规范语法都有了更多意识;
  • 事务与 ACID,专一于繁多引擎之后,简直每一条 SQL 都要思考事务与 ACID,须要对这些有更深的了解。

事务层

  • CN 与 DN 的适配,从架构降级开始,CN 与 DN 的分工与适配成为了微小难题,重复验证中失去了最优解;
  • 局部数据共享,Logtail 的引入,实现了某一部分数据在不同 CN 之间共享。

存储层

  • 应用 S3 存储,积攒了基于 S3 等对象存储的引擎开发教训,原来对象存储也能够很好地适配数据库;
  • Fileservice,一种存储服务,去实现不同节点不同底层存储类型的读写,是个极大的挑战。

Part 6 总结

矩阵起源公司成立于 2021 年,在上海、深圳、北京、硅谷等城市设有分支机构。团队成员由各领域专家组成,在分布式基础架构、数据库、大数据及人工智能畛域经验丰富。致力于成为行业当先的数据根底软件公司,帮忙所有企业和用户简略、麻利、高效地拥抱数据价值。

整个 MatrixOne 的架构降级之路,始于 0.4 迭代,在 0.6 迭代初步实现,历时半年多,数十位一线研发与测试工程师投入其中。删掉了关联的几十万行代码,又新增了体量更多的新代码。最终实现了从 share nothing 的 newSQL 架构到明天的新分布式 HTAP 架构,团队与产品独特取得了成长。

最初,让咱们总结一下 MatrixOne 架构降级的关键点:
▶ 从存算一体到计算、事务、存储三层解耦
▶ 从多引擎到繁多 TAE 的 HTAP 交融引擎
▶ 从因子化算法到 DAG 的打算构建
▶ 从多正本存储到对象存储与 Logtail 的引入
▶ 灵便调整节点调配带来的资源隔离

退出移动版