华为错误报告存放路径_华为Taurus云原生数据库论文分析

前言

多年以来，各云数据库厂商基于传统的单体数据库为客户提供了云上的数据库服务，满足了客户一定层次的需求：服务高可用、数据高可靠、完善的运营。然而，传统单体数据库架构存在严重的短板，无法满足客户更高层次的需求，所以近年来头部云厂商开始提供“云原生”数据库服务，克服了传统单体数据库的一些短板。

云原生数据库的主要特点是：

• 更好的弹性：占用空间随数据大小自动扩缩容，甚至可以做到计算资源随工作负载自动扩缩容，突破单机瓶颈。
• 更强劲的性能：云原生架构相对传统单机数据库，性能天花板更高。
• 更高的可用性：数据库崩溃恢复的时间比传统单机数据库更短，可用性得到提升。
• 更低的成本：添加额外的计算节点不需要增加额外的全量数据，节省成本。
• 所付即所得：客户所花的费用与实际消耗的计算资源、存储空间相关。

目前，国外的云原生数据库有：AWS Aurora、微软Socrates，都已经商业化。

国内的云原生数据库有：阿里云POLARDB、腾讯云CynosDB、华为Taurus。其中POLARDB、CynosDB都已经商业化很长时间，Taurus目前应该是还未商业化。

但是最近Taurus发表了一篇Paper《Taurus Database: How to be Fast, Available, and Frugal in the Cloud 》，详细介绍了它的架构特点、设计理念。本文对Paper中的内容进行一下概括。

背景

上述几个云原生数据库都是采用计算与存储分离的架构，存储层可以水平扩展支持上百TB的数据，计算层也可以垂直扩展以及水平扩展（添加只读实例）。但是如何做到计存分离，各自分法都有不同之处。

POLARDB通过将Innodb的log和page存放到类POSIX接口的分布式文件系统（PolarFs）来实现计存分离。这种做法看似很美好、对Innodb的侵入非常小，但是却有一些严重的问题，Taurus论文中有提及。 具体来说，大量刷脏的时候，持久化page的网络流量对于计算层、存储层都是一个很大的挑战，因为page流量是单纯log流量的几倍到几十倍不等，具体取决于用户的工作负载。另外，page刷脏会抢占log的持久化需要的资源（网络带宽、IO带宽），增大log持久化的延时，继而增大事务提交的延时。另外，由于PolarFs的基于raft（准确说是ParallelRaft）的数据复制方式，导致事务提交的路径上至少需要两跳网络传输，这个架构导致其需要在计算节点、存储节点都需要引入RDMA来减少网络带来的rt。

另外，我觉得POLARDB在通用分布式文件系统PolarFs上提供云原生数据库服务，多多少少在性能上、功能实现上被PolarFs限制，除非PolarFs针对db场景做定制，比如需要支持保存多个版本的page。

其实，计存分离的最优做法是采用“log is database”的理念，只需要把log写到存储层，由存储层负责重放log、回写page并尽量减少写放大。将刷脏这个操作从计算层剔除之后，可以降低计算节点的网络开销。Aurora首先采用这种做法，后续的Socrates、CynosDB、Taurus也均采用这个做法。

Aurora将db的数据（也即是所有page）分成若干个10GB大小的shard，相应的log也随data一起保存在shard中。每个shard有6个副本，采用N=6，W=4，R=3的策略，事务提交时需要等到log在至少4个副本持久化之后才能完成提交。Aurora的log持久化、page读取都只需要一跳网络传输。

Socrates也是采用“log is database”的理念，但是它单独了一个log层用于快速持久化log（具体实现不详），避免受到重放log、回写page的影响。另外，page svr层从log层拉取log进行重放、回写page，并向计算节点提供读取page的服务。但是page svr层只将部分page缓存在本地，全量的page在额外的冷备层。所以Socrates的读请求有可能在page svr层本地无法命中，进而从冷备层获取page。

CynosDB也是采用“log is database”的理念，从公开资料来看，存储层为计算节点提供了Log IO接口与Page IO接口，前者负责持久化log，后者负责page的读取。

Taurus也是采用“log is database”的理念，存储层分为Log Store、Page Store两个模块，前者负责持久化log，后者负责page的读取。log持久化、page读取都只需要一跳网络传输。

本文根据论文提供的信息对Taurus的设计进行简单介绍。

总体架构

Taurus包含四个主要的模块：SQL前端（修改过的MySQL）、嵌入到SQL前端的SAL library（ Storage Abstraction Layer）、Log Stores和Page Stores。其中SQL前端和SAL组成了计算层，Log Stores和Page Stores组成了存储层。如下图所示：