CCCF专栏｜云原生时代数据库的机遇与挑战

2022 年 4 月 27 日 中国计算机学会

云数据库模式相当于把传统数据库运维的工作托管后，对外提供标准化的产品能力，当用户想在云上申请一个数据库实例时，只需选择需要的数据库类型、版本以及资源规格等基础信息，就能从云上得到一个服务高可用、数据高可靠以及配备丰富监控报警指标等功能的数据库实例。

关键词：云时代数据库云原生

数据库在国内早期的使用情况

在计算机领域，数据库是一门相对古老的学科，拿关系型数据库的发展来说，从19世纪70年代关系型理论提出到现在已经有50余年了。比较典型的数据库产品有Oracle、SQL Server，还有开源的MySQL、PostgreSQL等。在国内的技术发展浪潮中，尤其是伴随着互联网的发展，数据库的业务场景越来越丰富，需要用到数据库的地方越来越多。早期各个公司更多使用的是像Oracle、SQL Server这类商业数据库产品，后来各互联网公司开始考虑成本、容量、业务压力等各方面因素，开始“去IOE”（是指摆脱IT部署中对IBM小型机、Oracle数据库以及EMC存储的过度依赖），大幅提升了像MySQL等开源类数据库产品的使用比例。

在传统的本地数据库使用模式中，各企业一般需要雇佣数据库管理员（DBA），采购单独的物理服务器，由DBA负责整个数据库的生命周期管理，包括初始化安装、系统参数调优等工作。DBA需要保障服务的高可用性，确保在机器宕机时，备库可以随时提升为主库对外服务。DBA也需要解决数据高可靠问题，及时做好数据备份，如有异常及时利用备份进行恢复。业务使用过程中的SQL往往也需要DBA根据经验提供优化建议，包括SQL的重写及库表索引的设计等。DBA的工作还包括分析运行过程中的监控指标观测及处理异常报警工作，以及伴随着业务量发生变化以后支持数据库的扩缩容等。除此之外还需要做好合规管控方面的工作，比如审计、权限管理等。

云数据库模式

伴随着云计算发展的时代趋势，云上各种基础设施服务能力的获取越来越方便，越来越多的企业选择将应用部署到云上，同时也开始选择使用云数据库。根据Gartner报告[1]对2011~2018年的追踪数据分析，云数据库的发展势头非常迅猛，头部15家数据库厂商中有4家是云厂商。用户愿意选择使用云数据库的原因主要包括：很多数据库产品只在云上提供或者优先在云上提供；云上的数据库产品具有足够的丰富度供用户灵活选择，以应对不同业务场景；拥有便捷的获取方式且完全按需付费，无须额外提前付出过多的预算成本。

下面分析一下云数据库是如何为客户服务的。各家云厂商会提供很多托管的数据库服务，包括国外的AWS、Azure以及国内的阿里云、腾讯云、京东云等都提供了多款云数据库服务，这种托管的数据库服务模式称为数据库即服务(Database as a Service，DBaaS)模式。例如京东云，提供了MySQL、SQL Server、PostgreSQL、MongoDB、InfluxDB、DRDS、TiDB、JDW、ClickHouse以及Redis、Memcached等十余种云数据库产品和服务，支撑了包括京东零售、物流、健康及科技等在内的集团所有业务，比如交易、支付、订单、分拣、配送等核心业务。云数据库模式相当于把传统数据库运维的工作托管后，对外提供标准化的产品能力，当用户需要在云上申请一个数据库实例时，只需选择需要的数据库类型、版本以及资源规格等基础信息，就可以在短短几分钟内从云上得到一个服务高可用、数据高可靠以及配备丰富监控报警指标等功能的数据库实例。

云上的数据库实例创建好后，其详情页面会包含这个数据库实例的一些基础信息，包括数据库类型及对应版本、所在地域、所在虚拟私有网络(Virtual Private Cloud，VPC)及其子网、域名、规格、只读实例等，此外，还有监控、账号管理、库管理、只读实例管理、性能优化、审计、安全管理、日志管理、变更配置、根据时间点创建/恢复、主备切换等各类信息的展示及对应的管理能力，非常直观地把传统数据库运维中需要人工操作的工作全部转换成通过简单易用的界面点击操作就可以完成的工作，对用户非常友好，也帮助企业节省大量的人力成本，让企业能够更加聚焦自身业务的主航道。当然不仅是云数据库，确切地说整个云计算的产品都具有类似的特点，这也是云计算技术给整个行业带来的时代红利。

云数据库实现原理

目前云上数据库的功能在底层是如何实现的？下面针对云数据库的一些比较重要的功能项展开分析。以MySQL产品为例，在云上申请一个数据库实例，包括一个主库和一个从库。主库与从库之间保持同步复制关系，一般情况下都是主库对外提供服务，从库隐藏，当主库异常时，从库将提升为主库。在主库前面一般会有一个负载均衡模块（LB），在LB前面会有一个域名系统（DNS），这样申请完数据库实例以后，就可以根据域名和数据库服务暴露的端口访问申请的数据库服务了。

数据库实例创建完后就已具备上文所述的一系列服务和能力，包括主从切换能力、备份及恢复能力、扩缩容（变更配置）能力，以及云上的控制台服务等。一个云数据库实例的完整架构如图1所示，绿色部分都是为数据库服务提供管理支撑的，包括云数据库自身的控制台服务、管理服务、哨兵服务、元数据库（用于存储每个云数据库实例本身的一些基础元数据信息，比如哪个用户拥有哪个数据库实例）等，其中哨兵服务的主要任务是在主库宕机后，第一时间发现并诊断这个节点是否确实有问题，当哨兵确认有异常，就会通知管理服务进行切换，将从库提升为主库，并将LB指向这个新的主库，再自动生成一个新的从库，从而确保用户的服务不受影响。除了上述管理服务以外，云数据库实例背后还包括其依赖的云上的其他服务，比如基础设施即服务(Infrastructure as a Service，IaaS)、云监控服务、对象存储服务等。

IaaS基础服务主要是为上层数据库服务提供对基础物理机的管理服务，通过调用IaaS暴露的API接口，数据库管理服务可以创建自己想要的虚机或容器，以及软件定义网络(Software Defined Networking，SDN)的一些资源（例如LB），以完成基础的数据库资源初始化工作。

云监控服务是各家云上都会提供的通用的监控报警服务，云数据库会将自己的监控信息上报给云监控服务，云监控将这些实例的各项监控指标展示给用户，用户还可以根据这些监控指标配置相应的报警项。

对象存储服务(Object Storage Service)提供的是低成本、强安全的云端存储服务，云数据库会将每个数据库实例的备份存储到对象存储上，包括定期的全量备份和实时的增量备份。与传统数据库DBA将备份存储到一些备份机上的做法相比，备份到对象存储上的数据更加安全，且对象存储服务可以当作一个无限容量的存储服务，对上层使用方来说能够节省大量的维护成本。

当云数据库的数据被实时备份到对象存储以后，用户在使用云数据库的过程中可以按需将这些备份恢复出来，比如在10：01时用户做了一个误操作，就可以通过时间点恢复，把数据库恢复到10：00前（即误操作前）的状态。在执行有风险的操作前，可以通过简单的点击按钮自动生成一个全量备份（称为手动备份），操作执行完成后，如不符合预期，可以把之前手动备份的数据重新恢复回来。在云时代以前，这些操作往往都是由专门的DBA操作的，而在云时代，普通开发人员通过控制台点击按钮就可以完成。

除了以上功能外，云数据库还有一个很重要的功能是可以在线平滑地扩缩容，这对用户来说是一个非常重要的功能。用户一开始可以选择较小的规格，并仅为这部分资源付费即可，当数据量或者业务访问量变大后，可直接在线提升规格，按业务需求来获取云上资源，不需要提前购置大规格的实例，从而降低资源和成本浪费。以本地盘存储的云数据库为例，具体的扩容过程如图2所示，有两种实现方式。一种是垂直扩容，指主从所在的物理机上还有空闲资源时，进行就地扩容，这种扩容方式不需要移动数据，扩容所需时间最短。另一种是迁移扩容，当数据库实例所在物理机剩余资源不足时，需要重新创建一个更大规格的主从，并将数据从原来的主从上迁移到新的主从上，这种扩容过程耗时相对较长，所需时间和数据量成正比。这两种扩容方式对业务都是无影响的，即使是迁移扩容，数据挪动的过程也是不影响业务正常访问的，只有当老主和新主数据完全同步以后才会将LB切换到新主上，对业务来说仅相当于做了一次普通的主从切换。

云原生时代

前面章节介绍了云数据库的一些实现原理，不管是云数据库、云缓存，还是云数据仓库，这类产品在云端生命周期管理的实现上有不少大同小异的地方。具体而言，每款产品的管理服务有一些基础功能是比较相似的，比如资源的创建、删除，监控项的采集汇总以及高可用切换的一部分功能等。鉴于此，在管理服务上通常选择基于Kubernetes（一个开源的 Linux 容器自动化运维平台，简称k8s）来开发云上的一些服务。k8s解决了资源编排的一部分通用问题，帮助基于其开发的产品节省了一些通用的管理成本，很多时候被认为是云原生（cloud native）的典型代表，其侧重点是对云上的资源管控做更好的编排，让上层应用在开发时更加便捷，推动应用开发从云时代向云原生时代迈进。

京东云基于k8s研发了云原生混合云操作系统“云舰”，帮助行业用户进一步加速迈向云原生时代。云舰作为混合云操作系统，通过对底层基础设施的抽象，统一管理多云的计算、网络、存储资源，屏蔽底层基础设施的差异，给用户提供多云一致的操作体验。云舰操作系统之上统一管理用户的业务系统，数据库中间件等平台即服务(Platform as a Service，PaaS)组件，以及大数据调度系统，完成业务系统发布部署管理，有状态应用的统一管理与跨云流量调度与故障迁移，以及通过混部技术实现资源的灵活混合部署，提供用户开放且多云一致的用户体验。

除了资源管理层面外，从数据库自身角度来看，当前各家云上的数据库大多没有真正摆脱传统数据库的影子，数据库层面仍然存在很多挑战性问题。以数据库存储数据使用的磁盘为例，在云上一般有两种：一种是本地盘，即CPU、内存、磁盘这些计算资源和存储资源都在一台物理机上，本地盘因单台机器磁盘空间有限，还受CPU、内存等资源的限制，扩缩容在实现上往往也相对麻烦；另一种是云盘，一种低时延、持久性、高可用的分布式块存储服务，与计算资源是分开的，从几G到十几T都可以非常方便地进行弹性扩缩。采用云盘的云数据库虽然具有更高的弹性扩缩容能力，但同时也存在一个问题：每块云盘本身是3副本的，数据库主从加起来就有6副本了，如果再添加只读实例，就得再加一块云盘，全局就有9副本了，容易造成资源浪费，同时针对数据库自身的日志处理、二次写(double write)以及云盘自身的一些机制组合到一起又会造成写放大的问题。

针对上述问题，AWS在设计理念上认为高吞吐量的数据处理瓶颈不在于计算和存储而在于网络，所以设计了一款数据库产品Aurora[2]，将计算和存储分离，存储设计为共享存储并可以分别独立扩容，且修改了主从复制的一些机制，把数据库重做日志（redolog）的处理下推到共享存储层进行，将网络I/O尽量降低，让主从节点共享同一份数据，避免存储资源的浪费。

Aurora这款产品整体上是非常成功的，它解决了存储成本和容量的问题，同时数据库性能表现比较优秀。这种模式的云数据库，更适合由云厂商提供，因为背后涉及了很多定制的服务或限制，包括硬件部署、网络方案等。

从云数据库厂商或者基础软件开发者的角度来看，在云时代该如何设计与云紧密结合的数据库产品或基础软件产品，这才是真正云原生的思考原点。这就需要回归到云到底有哪些基础能力的问题上。云最大的特点是按需付费(pay as you go)、弹性、近乎无限的容量，多地域(region)、多可用区(Availability Zone，AZ)，这些云的基础属性对未来的数据库以及更多的基础软件都将带来一场巨大的变革。比如云上的虚拟机，可以通过应用程序接口(API)方便地创建和销毁，如果有需要，可以在几分钟内创建出大量虚拟机，云上的对象存储可以提供PB级的存储容量，云盘服务可以通过API挂载到虚拟机上，也可以将云盘从一台虚拟机切换到另外一台虚拟机上，这些基础属性为上游数据库这类基础软件带来的变化就好比一座城市的道路由原来坑坑洼洼的泥土路变成现在宽阔平整的柏油路，原来与其他城市通的是绿皮火车，现在通了高铁和飞机，这些基础设施的变更必然带动这个城市的发展与繁荣。

可见，云厂商给现有基础软件带来冲击的同时，也给基础软件的未来带来了巨大的发展机会，如何设计与云深度结合的数据库产品，如何做一款真正的云原生的数据库产品是一件非常具有挑战也非常有意义的事情。目前业界已经有个别成功案例，比如Snowflake[3]，这是一款数据仓库产品，主要用于数据分析类场景，这款产品在规划之初就深度结合了云的能力，把云上资源的弹性创建、删除以及对象存储无限容量的这些基础特性发挥得淋漓尽致，同时为提升易用性把整个产品设计成软件即服务(Software as a Service，SaaS)模式，让用户无须关注购买机器、安装软件等，做到完全按需服务，极致弹性等。

以京东为例，京东的业务主要以在线交易为主，大量使用了联机事务处理(OnLine Transaction Processing，OLTP)数据库，每到“6.18”或“双十一”大促备战阶段，各个业务方都会提前将云数据库进行扩容，待大促结束之后再进行缩容。有些业务的数据量非常大，往往需要进行分库分表的工作，拆分后的数据库在分布式事务方面的保证以及如何平滑扩缩容、如何做全量及增量备份、如何快速恢复都是非常具有挑战的。在实际使用过程中，上下游业务之间除了业务上的调用关系外，还有对于数据变更的订阅关系，比如上游业务更改了某个商品的价格，下游有些业务需要感知到这种变化。这种关系在目前工程实践中是通过解析二进制日志（binlog），将变更操作记录通过消息队列服务（如Kafka）传递给下游业务，是否有其他方式可以通过直接监听数据库来实现。

再以京东的运营业务为例，分析人员会针对店铺或者商品的相关数据进行分析决策，直接在OLTP数据库上做复杂分析会影响到线上业务的运行。之前的做法是把数据同步到Hadoop体系的产品，每天晚上以T+1的方式提前运行分钟级甚至小时级的时间，对相关的数据进行提前分析计算并存储，第二天运营分析人员查询已经提前存储好的计算结果即可。后来我们提供了云数据库产品ClickHouse，其最大的特点是分析速度足够快，通过实时订阅上游数据库的变更日志，把数据同步到ClickHouse产品中，就可以做到近乎实时的业务计算分析，不仅节省了计算资源，还节省了原本需要存储大量计算结果的存储资源，而且由于计算分析响应足够快，很多分析的维度可以比T+1的方式做得更精细更灵活，原本需要几个小时甚至一天的分析和决策过程可以缩短到几分钟甚至几秒钟内完成，为上层业务带来巨大的商业价值。

实时的处理能力给上层业务带来了巨大的价值，即便如此，这种模式下的TP（事务处理型数据库）和AP（分析处理型数据库）本质上还是彼此分离的，云原生时代的到来，给TP和AP的融合提供了更多的可能性。我们是否有可能将数据完全统一到像Amazon S3这类对象存储服务上或者某个其他的云上基础存储产品中？依靠统一的存储产品的服务能力来保证数据的备份、恢复以及存储空间的扩缩容，对于上层的事务型的服务、订阅型的服务、分析型的服务所需要的数据，不用通过搬动数据的方式来实现，全局只需要一份数据就能满足上层不同业务的需求。不管是分布式的TP，还是单机的TP，不管是订阅变更还是实时分析数据或离线分析数据，站在业务的角度只需要关注自己的数据即可。当云原生数据库真正地站在以数据为中心的视角，将TP、AP、订阅变更甚至是不同业务间数据共享等各方面能力结合到一起时（如图3所示），必将给上层业务带来巨大的商业价值，并给整个工程领域上层业务体系的构建带来翻天覆地的变化。

从本质上看，用户关心的是数据而不是数据库，如何在云原生时代利用好云的按需付费、弹性、近乎无限容量等基础能力解决好用户与数据之间的交互并尽可能发挥数据的价值，或许是云原生时代的数据库需要长期不断深入思考的问题。

参考文献

[1] Adrian M, Ronthal A, Feinberg D. The Future of the DBMS Market Is Cloud[R]. Gartner, 2019.

[2] Verbitski A, Bao X, Gupta A, et al. Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases[C]// the 2017 ACM International Conference. ACM, 2017.

[3] Dageville B, Cruanes T, Zukowski M, et al. The Snowflake Elastic Data Warehouse[C]// ACM SIGMOD'16.2016:215-226.