盘点主流云原生数据库技术方案

　　作者：柯煜昌顾问软件工程师
　　目前从事RadonDB容器化研发，华中科技大学研究生毕业，有多年的数据库内核开发经验。
　　你将Pick这些内容：
　　云原生的概念
　　云原生数据库的概念
　　两种主流技术路线分析
　　六种云原生数据库方案和功能介绍
　　云原生数据库的核心功能和价值
　　背景
　　随着云计算的蓬勃发展，IT应用转向云端，云服务出现如下若干特点：
　　提供按需服务；
　　用户只愿支付运营费用而不愿支付资产费用；
　　云服务提供商集群规模越来越大，甚至遍布全球，集群达到云级规模（CloudScale）。
　　根据以上特点，要求云产品需要提供一定弹性（Elastic），而且达到云级规模；节点故障如同噪声一样不可避免，这又要求云服务有一定的自愈（Resilience）能力。
　　起初，通过借助IaaS，直接将传统的数据库搬迁到云上，于是出现了关系型数据库服务（RDS）。这样虽然能部分实现弹性与自愈，但是这种方案存在资源利用率低，维护成本高，可用性低等问题。于是，设计适应云特点的云原生数据库就至关重要。
　　RDS的挑战
　　以MySQL为例，如果要实现高可用或者读写分离集群，则需要搭建binlog复制集群。
　　图1：MySQL复制架构
　　如上图所示，除了页写入与doublewrite，redolog写入操作外，还有binlog与relaylog的写入。缺陷说明写放大严重如果以上架构中，FileSystem部署在分布式文件系统中，页的写操作，会因为副本复制的机制将IO放大，最后IO延迟也会放大。资源浪费严重1。binlog复制是为了适配MySQL所有存储引擎，属于逻辑复制。本质是将SQL在从实例执行（除了没有主实例的锁争用外，其他代价几乎一样），效率不高，也浪费了CPU与内存的资源。
　　2。扩展集群的计算能力时，不得不同时扩展存储空间，导致磁盘资源的浪费。备份恢复慢无论是物理备份恢复，还是逻辑备份恢复，备份操作均会上锁，影响正常业务进行，并且，备份恢复的时间也随着存储容量的增大而线性增长。扩展代价大
　　1。新增从实例，首先要从备份中恢复数据，然后应用binlog以达到与主实例一致的状态。这个过程耗时取决于恢复的时间以及binlog日志应用的时间，数据量大、数据状态过时的情况下，耗时费力而且不保证正确。弹性能力有限。
　　2。存储容量受限于单机存储容量，无法自由扩展。可用性低
　　Aurora〔1〕指出，在高规模的集群环境中，软件或者硬件故障如同背景噪声那样不可避免，并且缩短平均故障间隔时间（MTTF）是非常困难的，可行的方法是减少平均恢复的时间（MTTR）从而达到高可用性。
　　如上所示，RDS仍然是传统的备份恢复的方法修复故障，如果数据量大的话，可能是数小时，超过平均故障时间间隔（Aurora是10s），出现更多节点故障，可能使得共识算法无效（超过半数），可用性就大大打折扣。运维成本高备份恢复与扩展，均需要专业DBA团队运维，每个步骤出现错误需要人工检查。
　　云原生数据库简介
　　为了解决以上问题，需要针对云上服务的特点，改造或者开发新一代云数据库，这便是云原生数据库。特点说明计算存储分离对存储与计算进行解耦合，实现存储与计算分离。无状态计算节点无状态或较少状态。存储集群灵巧化采用小存储块方式组织副本，用以减少平均恢复时间，多副本共识算法，实现存储的高可用与故障自愈能力。
　　通过解耦合与少状态，计算节点扩展就会很轻量，扩展速度近乎进程启动的速度。避免扩展计算资源的时候，不得不浪费存储资源的窘境。
　　解耦合也使得存储节点也少了一定的约束，可以使用成熟的分布式存储技术实现灵巧化，降低运维成本提高可用性。
　　接下来将介绍目前两种主流的技术路线和几种知名的方案。
　　1Spanner类
　　以Google的Spanner〔2〕为代表，基于云原生开发全新的数据库。受其影响，产生了CockrochDB、TiDB、YugabyteDB等产品。
　　1。1架构
　　以TiDB〔3〕架构图为例：
　　图2：TiDB架构图
　　总体来说，此类产品其特点都是在keyvalue存储基础上包装一层分布式SQL执行引擎，使用2PC提交或者其变种方案实现事务处理能力。计算节点是SQL执行引擎，可以彻底实现无状态，本质是一个分布式数据库。
　　1。2存储高可用性
　　Spanner将表拆分为tablet，以tablet为单位使用多副本Paxos算法实现。
　　TiDB为Region为单位使用多副本MultiRaft算法，而CockroachDB则采用Range为单位进行多副本，共识算法也是使用Raft。
　　Spanner中keyvalue持久化方案，逻辑上仍然是基于日志复制的状态机模型（logreplicatedstatemachines）上再加共识算法实现。
　　图3：multiRaft存储架构
　　1。3优缺点
　　说明优点
　　彻底的ShareNothing
　　号称全球部署
　　使用keyvalue结构与LSM树，以及日志复制自动机机制，天然无写放大效应
　　不需要人为分库分表，有很好的横向扩展能力缺点
　　全新开发工作量大，技术不算成熟
　　性能不佳
　　事务处理能力有限
　　在内存中处理事务冲突，有冲突的需要读写等待或者提交等待。
　　如：Spanner对有冲突的事务TPS能力最大只有125
　　SQL支持能力有限
　　如：YugabyteDB不支持Join语句
　　2Aurora类
　　Aurora是亚马逊推出的云原生数据库。与Google的技术路线不同，Aurora是传统的MySQL（PostgreSQL）等数据库进行计算与存储分离改造，进而实现云原生的需求，但其本质仍然是单体数据库的读写分离集群。
　　Aurora论文对Spanner的事务处理能力并不满意，认为它是为Google重读（readheavy）负载定制的数据库系统〔1〕。这种方案得到一些数据库厂商的认同，出现了微软Socrates、阿里PolarDB、腾讯CynosDB、极数云舟ArkDB以及华为TarusDB云原生数据库等。
　　2。1架构
　　Aurora架构如下：
　　图4：Aurora架构
　　下图绿色部分为日志流向。
　　图5：Aurora网络IO
　　由于传统数据库持久化最小单位是一个物理页，哪怕修改一行，持久化仍然是一个页，加上需要写redo日志与undo记录，本身就存在一定的写放大问题。如果机械的将文件系统替换成使用分布式文件系统，并且为了实现高可用采用多副本，则写放大效应进一步放大，导致存储网络成为瓶颈而性能无法接受。
　　Aurora继承了Spanner的日志持久化的思想，甚至激进提出日志即数据库的口号，其核心思想是存储网络尽量传输日志流，对于读操作，存储网络传输数据页在所难免，但是计算节点可以通过bufferpool来优化。
　　它对传统数据库进行了如下改造：
　　数据库主实例变成计算节点，数据库主实例不再进行刷脏页动作，仅仅向存储写日志，存储应用日志实现持久化，即日志应用下沉到存储。数据库主实例没有后台写动作，没有cache强制刷脏替换，没有检查点；
　　数据库复制实例获取日志内容，通过日志应用更新自身的buffercache等内存对象；
　　主实例与复制实例共享存储；
　　将崩溃恢复，备份、恢复、快照功能下放到存储层。
　　并且，以原有S3存储系统为基础，对存储进行如下改造：
　　将存储分段（Segment），以10G作为分段单位大小，每个分段共六个副本，部署于三个可用区（AvailableZone），每个可用区两个副本，Aurora将这六个分段称为一个保护组（ProtectionGroup，PG），实现高可用。
　　存储节点能接收日志记录应用来实现数据库物理页的持久化，并且使用Gossip协议同步各个副本间的日志。
　　存储能提供多版本物理页，用以适配多个复制实例的延迟。并且后台有历史版本页面回收线程。
　　持久化页存储流程图如下：
　　图6：持久化存储流程
　　2。2高可用
　　Aurora采用仲裁协议（Quorum）多数派投票方式来检测故障节点。这种高可用的前提是，10G分段恢复时间为10秒，而10秒内出现第二个节点故障的可能性几乎为0。
　　它采用3个可用区，可以形成46仲裁协议（6个节点，写需4个投票，读需3个投票）。最坏情况是某个可用区出现灾害（地震，水灾，恐怖袭击等）时，同时随机出现一个节点故障，此时仍然有3个副本，可以使用23仲裁协议（3个节点，写需2个投票，读需2个投票）继续保持高可用性（AZ1高可用）。
　　说明优点
　　在成熟的数据库系统进行改造，技术相对成熟稳定、工作量小
　　事务处理能力，性能能保持传统数据库的优势缺点
　　本质仍然是改良的读写分离集群
　　有修改一行写一个页的写放大问题，需要小心处理
　　需要proxy等组件才能支持分布式事务
　　3CynosDB方案
　　CynosDB〔9〕几乎复刻了Aurora的实现方式，但是有其自身的特点：
　　存储多副本之间用Raft算法保证高可用，Raft算法包含了Quorum仲裁算法，而且更加灵活；
　　与Aurora一样，主从计算节点通过网络传输redo日志，同步双方的buffercache以及其他内存对象。
　　4PolarDB方案
　　图7：PolarDB架构
　　PolarDB〔5〕也是存储与计算分离架构，但与Aurora最大的不同，就是没有将redo日志下放到存储进行处理，计算节点仍然要向存储写物理页，仅主实例与复制实例之间使用redo日志进行物理复制同步bufferpool〔4〕、事务等其他内存对象，使用现有的分布式文件系统，不对其进行改造。
　　PolarDB目前集中于分布式文件系统优化（PolarFS），以及查询加速优化（FPGA加速）。
　　5Socrates方案
　　图8：Socrates架构
　　Socrates〔7〕是微软新研发的DaaS架构。与Aurora类似，使用存储与计算分离架构，强调日志的作用。但是Socrates采用的复用已有SQLServer组件：
　　SQLServer为了支持Snapshot隔离级，提供了多版本数据页（PageVersionStore）的功能；
　　使用SSD存储作为bufferpool的扩展（ReslilientCache），可以加速故障崩溃恢复过程；
　　RBIOProtocol是扩展的网络协议，用以进行远程数据页读取；
　　SnapshotBackupRestore快速备份与恢复；
　　新增XLogService模块。
　　其特点如下：
　　尽量复用了原有SQLServer的特性，使用SQLServer组件充当PageServer，模拟Aurora的存储节点；
　　Socrates有一个很大的创新，日志与页面存储分离。它认为持久性（durability）不需要使用快速存储设备中的副本，而可用性（availability）不需要有固定数量的复制节点。因此XLog和XStore负责durability，计算节点和pageserver仅用于可用性（它们失效的时候不会丢数据，仅仅是不可用）；
　　redo日志传递均借助XlogService，而不是通过主从计算节点通过网络传输。主实例节点不需要额外进行日志缓存来适应从实例节点。
　　6TaurasDB方案
　　图9：TaurasDB架构
　　TaurasDB〔8〕架构如上图，它继承了Aurora的日志下沉存储的思想，也继承了Socrates的日志与页面存储分离的思想，并且在计算节点添加了存储抽象层（SAL）。LogStore与PageStore采用与Aurora类似的Quorum仲裁算法实现高可用。
　　总结云原生数据库的核心功能
　　计算与存储分离，计算节点保持少状态，甚至无状态；
　　基于日志的进行持久化；
　　存储分片分块，易于扩容；
　　存储多副本与共识算法；
　　备份、恢复、快照功能下放到存储层。
　　知名方案的非核心功能
　　图10：非核心性能支持情况
　　【全球部署】
　　多机房升级版，需要考虑全球可用性，全球分布式事务能力，以及GDPR合规要求的地理分区（GeoPartitioning）特性。
　　由于欧盟出台通用数据保护条例（GDPR）〔6〕，使得数据不得随意跨境转移。违者最高罚款2000万欧元，或者全球营收4。原有分布式库处理技术，例如使用复制表进行Jion优化，就存在违规风险。此外，国内以及其他国家均有类似的数据保护法规，合规性将来也会是重要的需求。
　　云原生数据库的核心价值
　　【更高的性能】
　　基于日志进行持久化与复制更轻量，避免写放大效应，各大厂商均号称比原版MySQL有5～7倍性能。
　　【更好的弹性】
　　计算节点无状态或少状态，计算节点与存储扩展灵活。
　　【更好的可用性】
　　将数据库持久文件分片，以小粒度方式副本方式降低MTTR，以及共识算法来实现高可用。
　　【更高的资源利用率】
　　计算能力与存储容量按需伸缩，减少资源浪费。
　　【更小的成本】
　　更少的资源、更少的浪费、更少的维护，最终达到更小的成本。
　　云原生数据库本质是用现有技术组合，实现云原生需求，而且也是数据库实现serverless的必由之路。
　　参考文献
　　〔1〕：AmazonAurora：DesignConsiderationsforHighThroughputCloudNativeRelationalDatabases
　　〔2〕：Spanner：Google’sGloballyDistributedDatabase
　　〔3〕：TiDB：ARaftbasedHTAPDatabase
　　〔4〕：PolarDBredoreplicationhttps：www。percona。comlive18sitesdefaultfilesslidespolardbp18slides。pdf
　　〔5〕：PolarDBArchitecturehttps：www。intel。comcontentdamwwwpublicusendocumentssolutionbriefsalibabapolardbsolutionbrief。pdf5
　　〔6〕：GDPRhttps：gdprinfo。eu
　　〔7〕：Socrates：TheNewSQLServerintheCloud
　　〔8〕：TaurusDatabase：HowtobeFast，Available，andFrugalintheCloud
　　〔9〕：腾讯云新一代自研数据库CynosDB技术详解架构设计https：cloud。tencent。comdeveloperarticle1367387
　　文中图片均来自以上参考链接
　　抽奖活动
　　参与活动，送出价值79元的《云原生：运用容器、函数计算和数据构建下一代应用》一本。
　　推荐语：Azure计算团队的产品架构师撰写，现代云原生应用开发入门实践指南。本书旨在能够提供一些基础知识，来帮助开发者和架构师更从容地开启云原生应用之旅。
　　内容简介
　　探讨设计云原生应用所需的技术
　　介绍容器和函数计算的区别，并学习它们的适用场景
　　有针对性地设计应用来满足数据相关的需求
　　学习DevOps的基础知识和一些开发、测试、运维实践
　　学习一些构建和管理云原生应用的技巧、方法和实践
　　理解构建一个具有可移植性的应用所需的代价，并且学会对需求做出取舍
　　关于RadonDB
　　RadonDB开源社区是一个面向云原生、容器化的数据库开源社区。为数据库技术爱好者提供围绕主流开源数据库（MySQL、PostgreSQL、Redis、MongoDB、ClickHouse等）的技术分享平台，并提供企业级RadonDB开源产品及服务。
　　目前RadonDB开源数据库系列产品已被光大银行、浦发硅谷银行、哈密银行、泰康保险、太平保险、安盛保险、阳光保险、百年人寿、安吉物流、安畅物流、蓝月亮、天财商龙、罗克佳华、升哲科技、无锡汇跑体育、北京电信、江苏交通控股、四川航空、昆明航空、国控生物等上千家企业及社区用户采用。
　　RadonDB可基于云平台与Kubernetes容器平台交付，不仅提供覆盖多场景的数据库产品解决方案，而且提供专业的集群管理和自动化运维能力，主要功能特性包括：高可用主从切换、数据强一致性、读写分离、一键安装部署、多维指标监控告警、弹性扩容缩容、横向自由扩展、自动备份恢复、同城多活、异地灾备等。RadonDB仅需企业及社区用户专注于业务层逻辑开发，无需关注集群高可用选型、管理和运维等复杂问题，帮助企业及社区用户大幅度提升业务开发与价值创新的效率！
　　GitHub：
　　https：github。comradondb
　　微信群：请搜索添加群助手微信号radondb