【前言】Taurus是华为对标AWS Aurora的一款重磅云原生数据库。其设计思想是Log-as-database以最小化网络IO，采用计算存储分离的架构。Taurus的市场定位是OLTP的企业级市场以及高端MySQL客户，但兼顾中小客户。技术路线上兼容MySQL/PG生态，减少客户获取成本，降低风险。本文介绍Taurus数据库产品产生的背景、系统架构以及技术细节。此外，我们还对比了AWS Aurora/Aliyun PolarDB与Taurus的一些特性。
相关背景
图1. 第一代云数据库系统架构
在移动互联和物联网等新的应用场景之下，半结构化与非结构化数据例如图片、文本、音频、视频等出现爆炸性增长。传统数据库系统难以应对大数据时代下的存储需求，企业客户迫切需要新的数据库产品，具备动态扩缩容、高吞吐量、低成本等。在云计算技术不断成熟的背景之下，云数据库开始崛起，并因为按需扩展、按需付费等优异特性获得中小企业及互联网客户的青睐。云数据库经历了若干时期的发展，逐渐从托管式服务进化到云原生数据库。云原生数据库在某种程度上颠覆了传统数据库的架构设计。因为云环境基本已经提供相应的高可用功能，而大部分云厂商提供的数据库服务并没有利用这个特性从而错过许多优化空间。以MySQL为例子，如图1所示，数据库系统部署在虚拟机和分布式块存储之上。每个数据库有一个主实例和至少一个只读实例。外部客户通过一个虚拟IP(VIP)访问数据库。当主节点发生故障，云端管理软件会将VIP自动切换至新的主实例。主实例和只读实例都将数据存放在云存储的块设备上。主实例将数据页、保证页面原子性的double write以及redo日志通过文件系统接口写入云存储侧，然后将binlog发送到只读节点。只读节点接收到这些binlog之后写入relaylog，然后回放日志重建数据库副本。回放线程也会将这个过程产生的redo日志，binlog和数据页写到云存储。整个系统可以工作，但是却存在如下几个问题。
l 存储空间浪费
为了确保数据的可靠性，云存储对于写入的数据一般都是采用3副本存储。所有的数据库实例包括主实例和只读实例都是将数据写入云存储。这种情况下，主实例是3副本存储，其它只读实例也是3副本存储，总共消耗3*(N+1)副本的存储空间，其中N为只读实例的个数。理想情况下，整个数据库系统只需为主实例保留一份数据，只读实例可以共享这份数据，那么可以极大地节省存储空间。
l 较大的RTO和数据滞后
在现有的RDS部署中，数据库系统的高可用取决于主备之间binlog同步和故障切换协议。在事务提交之前，主机将binlog同步至备机，等待备机的ACK。备机将接收到的binlog进行回放，重建数据库副本。主机发生故障的时候，备机只有将binlog回放完成才能接管系统，对外提供服务。
在云环境，MySQL将数据存储在远端的分布式云存储上。数据库日常操作产生的磁盘IO都会转化成网络IO。对比本地存储，云存储的优点在于提供了更大以及更可靠的存储空间。它的主要不足在于延迟较大。这直接影响了备机binlog回放性能。虽然MySQL5.6支持MTS特性，但是一个库只有一个回放线程。在最坏的情况下，需要等待数小时备机才能就绪，对外提供服务。MySQL5.7引入MTS多线程并行回放特性，但是帮助有限，这仍然不能从根本上解决问题。本质上而言，主库的更新压力越大，从库回放日志的时间也就越长，接管系统等待的时长随之增加。因此系统的RTO增大。由于从库需要回放日志来反映主库上的更新，备机回放性能的不足使得主从延迟较大。理想的情况下是，主备共享云端的数据，这可以完全消除备机回放过程和开销，极大地缩小RTO和主从滞后。
l 计算资源浪费
在现有的RDS部署中，创建备机的主要目的是回放binlog，备机不响应任
何的客户端请求。这其中主要的原因是防止查询工作负载影响回放进程。类似地，只读副本系统的回放进程也会影响查询性能。如果备机能够消除回放过程，那么系统的所有计算都可以用来相应用户请求。
l 系统性能
RDS MySQL主实例将redo日志、binlong和数据页(双写)写入远端的分布式云存储。当系统redo存储空间或缓冲区脏页比例达到阈值，MySQ进行checkpoint操作将脏页写入云存储。对比本地存储，云端较大的写时延制约系统的性能，特别是写入性能。在AWS Aurora纯写测试基准下，现有MySQL RDS的QPS是50~60K，而Aurora能够到达110k。在64个虚拟处理核心下，Aurora甚至能够达到200K的QPS。
l 网络带宽消耗
在当前的RDS部署中，所有数据库实例都会通过网络将其所有数据写入后端云存储。以master为例，一个MySQL master实例需要写redo日志、binlog和数据页(双写)。对于Aurora纯写测试基准，峰值吞吐量为200 K QPS，这转换为70 M字节/秒的重做日志，但是，写数据页将生成另外700 M字节/秒的流量。对于云存储，所有这些都是多副本存储。这仅对于单个数据库实例。在这种带宽消耗规模下，在相同基础架构上运行的数据库实例数量将会很少。
此外还有写入放大、大库支撑不足和从库加入时间较长等问题。Amazon首先意识到上述问题，近年来推出的云数据库Aurora就是为云计算时代而专门定制的一款关系型数据库。其目标主要是最小化网络IO，充分利用云基础设施来提升系统的可扩展性与可用性。Aurora的设计哲学是log is database，对数据的更改只写日志，不刷脏页，极大地简化恢复子系统。Amazon宣称Aurora的RTO最大为2分钟左右；可以在秒级时间内完成故障节点切换与扩容，性能对比MySQL5.6可以优10倍。
TaurusDB作为一款cloud native的数据库，设计理念类似AWS Aurora，但青出于蓝而更胜于蓝。TaurusDB不仅针对IO与写操作进行了优化，而且还考虑了读优化，让应用程序可以在缓冲区内以最小的代价获得最新的数据，明显区别于国内厂商（腾讯CynosDB基本完全按照AWS Aurora的设计思路，与TaurusDB原型版本设计思路类似，这里我们把它归为AWS Aurora一类）。TaurusDB针对用户痛点进行了相应的技术革新，对比第一代云数据库其优点相当明显。以下是TaurusDB的架构设计，文章的最后是TaurusDB与其它厂商的对比。
图2. 基于DFV共享存储的TaurusDB架构
TaurusDB是华为MySQL RDS经历了云盘时代单机版、Active-Standby主备版和金融高可用一主两备三节点架构版本后，作为华为云自研的最新一代cloud native分布式数据库。它采用华为下一代云存储（DFV）实现弹性扩缩容、高可用和共享存储。如图2所示，系统自顶向下分为3大部分，SQL节点、存储抽象层SAL(Storage Abstract Layer)以及存储节点(storage server)。TaurusDB SQL节点形成一个集群，包括一个主节点和多个只读副本（RO，最多15个）。每个集群属于一个云租户，一个租户可以具有多个集群。SQL节点管理客户端连接，解析SQL请求，生成查询执行计划，执行查询以及管理事务隔离。主节点和只读副本之间的通信流量很小，主要交换一些状态信息（DDL更新、slice/pages分配更新和活跃事务列表、只读副本中最旧的读取视图、副本最小LSN）。在故障切换期间，任何只读副本都可以接管集群。只有主SQL节点负责数据库更新和DDL操作，而只读副本处理数据库只读查询，并为客户端提供可重复读（RR）和读已提交（RC）隔离级别。
如图2所示,SAL(存储抽象层)是SQL节点和存储层之间的桥接器。SAL包括两个主要组件，SAL SQL模块和DFV存储节点内部的Slice存储。SAL SQL模块为SQL节点（主/只读副本）提供了SAL API，用以与底层存储系统进行交互。如图3所示， SAL SQL模块包含通用日志处理器CLP（Common Log Processor）、数据库分片管理器SM（Slice Manager）、页面读取器PR(Page Reader)以及与只读副本节点同步信息的工具程序。CLP负责将数据库全局重做日志持久到DFV，解析日志并将其分发到相应的DFV分片，并生成同步消息（脏页，活动事务列表，分片持久LSN等）以供只读副本获取。CLP还需要处理数据库崩溃恢复，重新加载已提交的全局重做日志并将其重新分配给所有相应的分片。SM维护分片策略以及页面映射信息，确定何时添加更多的分片以及哪些数据库页面应分配给哪个DFV切片等。页面读取器负责通过查找页面映射信息将特定的页面读取请求路由到相应的切片管理器。SAL SQL模块还为SQL节点与存储系统交互提供了其他一些接口，包括定期将日志清除信息（RecycleLSN）传递到数据库片等。
图3. SAL-SQL包含的主要模块
Slice Store是在DFV存储节点内部运行的插件模块。它需要与DFV存储框架一起使用，用以在相同DFV节点上管理多个数据库片，支持多租户资源共享，并将页面的多个版本提供给SQL节点。如图4所示，对于每个分片，slice Store使用日志目录作为中心组件来管理重做日志和页面数据。Slice store的主要职责是1) 接收分片重做日志，将其持久化并注册到日志目录中；2)接收页面阅读请求并构建特定版本的页面;3)垃圾回收和合并日志。
图4.slice store组件
TaurusDB存储层建立在华为云存储DFV持久层之上。DFV持久层为上层SQL节点存储提供读写接口，提供跨地域3AZs之间的数据强一致性和可靠性保证。 TaurusDB使用两种模式实现write-optimized以及read-optimized，分别是PLOG模式与iShard模式。PLOG模式提供强一致性保证，而iShard模式实现最终的一致性。TaurusDB SQL节点使用PLOG模式存储整个数据库的WAL重做日志，使用iShard模式对数据在多个存储节点之间进行分片和管理。PLOG以SSD友好的追加写方式使事务提交更快；iShard将redo以页面为单位进行聚合，管理数据分片，实现快速数据读取，并支持超大型数据库（128 TB）。存储层支持多个TaurusDB集群实例，单个存储节点支持多租户数据库分片。部署灵活，可以将PLOG和iShard部署在单独的存储池中或共享同一存储池。
在这种体系架构下，整个数据库集群只需一份足够可靠的数据库副本集，极大地节约成本。所有只读副本共享在云存储中的数据，去除数据库层的复制逻辑。一写多读，没有独立的备用实例。主节点发生故障，集群进行切换操作时，只读副本都可以切换为主节点，接管集群服务。为了节省宝贵的网络带宽，只有数据库日志通过网络从数据库计算节点写入 DFV 存储层，没有脏页、逻辑日志和双写的流量。基于 DFV 存储层内的数据库日志重构数据面，独立于上层的计算节点，实现存储和计算分离。为了应对大数据存储需求，TaurusDB利用DFV的切片策略对数据库进行自动分区，对应用透明。单个DFV存储节点可以管理来自不同数据库集群实例的多个分片，实现存储容量无限扩展。TaurusDB的设计中，充分使用了异步线程、批量IO以及流水线工作模式实现写入高性能。这对于有大量写入需求的场景，例如物联网是相当合适的。通过在存储层内嵌数据库插件可以快速读取所需的数据。从这一角度上来说，TaurusDB是一个write-optimized以及read-optimized的数据库系统。总的来说，TaurusDB具有以下的优点：
1. 节省资源
如上所述，TaurusDB只需一份足够可靠的数据库副本集。所有只读副本共享云存储中的数据。添加只读节点时，只需添加计算节点，无需额外购买存储。只读节点越多，节省的存储成本越多。另外一个值得注意的地方就是数据库去除了复制逻辑，对比主备高可用架构这在一定程度上了节省了网络流量，提升计算节点效率。总体而言，在成本开销上，TaurusDB提供企业级的服务能力，但只有1/10商用数据库的成本。
2. 便捷扩展性与高可靠性
在第一代云数据库的主从架构下，添加只读时需要拷贝数据，重放 binlog，这要求备库完整地执行一次查询请求，在大数据量情况下速度很慢，尤其是对于采用本地盘方案。主从复制延迟问题会影响主备切换，无法保证 RTO，影响SLA。此外，备份恢复速度很慢，TB级的数据量通常需要耗费数小时，使得数据库扩展性严重受限。对比传统的逻辑复制，物理复制则没有上述缺点。因为物理复制只需在日志指定的存储位置上恢复/应用数据的前置镜像/后置镜像即可，完全跳过了查询执行过程。TaurusDB采用物理复制，减少IO操作的同时，让复制更加可靠、高效，并且几乎不会对性能造成影响。由此带来秒级主备切换、快速动态的读扩展和故障恢复。TaurusDB最高支持扩展到15个只读节点。虽然TaurusDB使用了物理复制，但是基于客户在数据分析和传输上需要Binlog，我们也支持Binlog进行数据同步。
得益于底层强一致分布式文件系统DFV的支撑以及TaurusDB架构在数据访问上的设计，TaurusDB支持跨AZ部署，跨region容灾，实现单点故障0中断，满足金融级别可靠性。
3. 高性能
TaurusDB包含MySQL 8.0的所有重要功能，还在其基础之上进行了大量的优化，例如针对硬件特性的适配与大并发下的优化。TaurusDB对封锁子系统进行了分区，减少了锁表的竞争，并行化死锁检测；在事务子系统上采用Lock-Free数据结构来管理事务子系统的活跃事务列表。除此之外，引入内核特性，例如Query result cache，Query plan cache，Online DDL等提升用户体验。
相比于TaurusDB1.0版本，TaurusDB2.0版本在性能表现上有了显著提升，在关键情况下都有了数倍的改进。对比MySQL 8.0的官方版本，TaurusDB2.0的优化改进所带来的效果也非常明显，尤其是物理复制方面具有显著的优势。在纯写情况下，TaurusDB2.0的性能可以比官方MySQL8.0高7倍以上。
4. 强悍的备份恢复支撑
TaurusDB 引擎采用定制的新一代分布式存储系统DFV，极大提升了数据备份、恢复性能。DFV持久层集群包括多个存储节点。每个存储节点包含多个SSD设备和适应SSD介质的append存储服务进程，提供AppendOnly vs. WriteInPlace的数据写入模式。DFV将数据按多时间点多副本存储，支持海量快照和快照秒级生成。在这种能力支撑之下，基于底层存储系统的多时间点模式，TaurusDB不需增量日志回放，可直接实现按时间点回滚,轻松支持PITR（Point-In-Time-Recovery）特性。TaurusDB将特定计算任务（备份与恢复逻辑）下推到DFV，以便更高效，快速地实现备份、恢复，而上层计算节点专注于业务逻辑处理。在这种模式之下，客户可以通过本地访问数据并直接与第三方存储系统交互，高并发高性能。通过异步数据拷贝外加按需实时数据加载机制， TaurusDB 可在数分钟内达到完整功能可用，实现快速实例恢复。
横向比较
TaurusDB 的共享存储架构将数据持久化放入新一代存储中，充分保障数据强一致性和 0 丢失；针对硬件定制上层系统，充分利用 RDMA 网络、NVME SSD 等硬件优势，在这些关键技术上整合创新，使得 TaurusDB 的性能有了质的飞跃。对比目前业界的同类型产品，AWS Aurora和阿里的PoloarDB，TaurusDB的纯写性能方面要优30%左右。从阿里云对外公布的技术资料分析，PolarDB仍然需要将数据页写入存储侧，对数据进行SSD不友好的update-in-place操作。相比Aurora，PolarDB在体系结构上进行了一些创新，例如与数据库交互的IO设计、与现代硬件的适配等。腾讯的CynosDB则基本上参照AWS的Aurora进行设计，也沿用了很多系统概念例如数据段一致LSN(SCL)，MTR完全点(CPL)，最大存储卷MTR完全点(VDL)等。TaurusDB为了应用程序能够在计算节点以最小代价读到最新的数据，另辟蹊径对系统架构进行了不同层面的思考。利用CLP组件实现快速事务提交，利用slice store达到读优化的目的。在这点上，TaurusDB跟SAP HANA的设计思路有类似之处，数据在系统不同阶段有不同的作用。SAP HANA中，数据从行存储形态逐渐转化成列存储，从写优化向读优化演变；而TaurusDB中，日志从开始阶段的写优化通过compact操作向读优化演进。日志兼顾保证系统的持久性与效率。在不同的时期，日志的作用不同。系统恢复阶段，日志通过回放将系统恢复到最新一致性状态；在系统正常运行阶段，日志通过回放将系统最新数据提供给应用程序。并且得益于对多版本数据的剪枝（页面解析plug-in），计算节点可以以最小的代价从存储节点获得最新数据，无需RDMA网络的支撑即可高效完成。这也是TaurusDB能够顺利实现跨AZ部署，跨region容灾的关键点。表一是从用户较关心的角度出发，对TaurusDB，AWS Aurora以及阿里PolarDB“三驾马车”的横向对比。
表一 TaurusDB VS. PolarDB VS.Aurora
| RPO (PITR) | RTO | MySQL/PG兼容 | 系统纯写性能比率 | 支持跨AZ | 只写log | |
| TaurusDB | Y | <=30sec | Y | 1 | Y | Y |
| 阿里PolarDB | Y | >=1min | Y | 0.7 | N | N |
| AWS Aurora | Y | <=30sec | Y | 0.7 | Y | Y |
企业博客