云数据库 UDB 的三重境界（四）

三位一体融合平台：云计算 2.0 下的内生进化

UDB 产品在第一、二阶段的成长和发展是基于公有云场景，围绕成熟的数据库软件和解决方案来为用户创造使用价值。这种模式清晰明确，但也存在不少短板。

1.最大的问题在于传统的数据库软件的架构和代码已不适应公有云发展的需要。传统数据库在分布式、容灾、最新硬件的利用上都存在硬伤。

2.用户对云数据库提出的新需求，传统数据库已不能满足。比如大数据量的高效备份、OLTP 和 OLAP 融合、异构数据库等问题，传统数据库没有很好的解决方案。

3.一些需要定制化的、特定场景下数据库需求，传统数据库也不能照顾到。比如，很多客户不愿意上云，重要的一点原因是数据的安全保护；而相关技术，如同态加密等还只停留在理论阶段不具备实用性。如果能够让客户将数据加密后再写入云数据库，通过定制化的计算节点，根据业务需要提供对密文数据的计算，且计算效果等效于明文，那么数据的安全问题将迎刃而解。

4.第三个问题是数据库运维的方法仍然传统。当数据库实例和客户量达到一定的规模后，传统的人工运维的方法已变得不切实际。解决之道就是数据库运维自动化和智能化，DBA 变身自动化和 AI 系统训练师，持续地把运维经验和方法沉淀到智能化系统中，构建良性循环。

我们不可能用产生问题的方式去解决问题。上述问题来源于传统的数据库架构和运维方式，因此不可能再用传统的方式来解决。唯一解决之道在于依托云计算 2.0，实现云数据库的内生进化。摆脱传统模式的窠臼，开创云数据库的新境界。

近年来公有云基础设施的优化、分布式技术的发展，为云数据库的内生进化提供了有力的技术支撑：

1.高速网络和 RDMA 技术，从 HPC 领域逐渐被引入到公有云基础设施之中，促使服务器间的通信延迟有数量级的降低。

2.更多高性能硬件层出不穷，比如更加强劲的 CPU（Skylake）、3D XPoint 闪存（Optane）等。这些硬件技术的出现，赋予数据库工程师在数据库性能优化上更多的选择和可能性：除了软件架构调整、重构等传统方法外，还可以充分利用硬件优势进行加速。

3.Paxos/Raft 协议的工业化实现和应用为分布式系统容错提供了强有力的武器。分布式系统的错误适应能力、恢复速度、自治能力有显著提高。

4.Docker 和 Docker 编排技术的出现极大拓宽了公有云资源管理和部署的想象空间，全新的资源部署、使用、管理方式不断涌现。

5.云数据库团队过去在大规模资源部署和管理、数据库内核/分布式数据库研发等领域积累的经验，在 DBA 领域沉淀的智慧，为实现换代式进化提供了坚实的实施基础。

因此，在云计算从 1.0 向 2.0 跃迁的关键时间节点上，UDB 团队提出未来发展的三位一体战略来刻画未来云数据库的技术和产品形态，满足未来客户的普遍需求：

a.计算和存储分离，内部架构同一化

b.一套架构多种定制：对外需求支持多样化

c.深度学习：数据库运维智能化

上述三个支点构成一个云数据库产品整体体系，将有力支撑 UDB 产品面向未来的发展。

计算和存储分离，内部架构同一化

数据大规模增长的趋势下，单机数据库的容量和性能显得捉襟见肘，但十几年来出现的各种分布式数据库解决方案均无法确保在容量和性能扩展同时，做到如同单机数据库一样使用和访问体验。根本的原因在于存储能力扩展、计算能力扩展和数据强一致这三者无法妥善兼顾。

如何实现三者兼顾，现阶段依然是一个悬而未决的难题。但从近些年公有云上的新产品（Aurora、PolarDB）来看，在做到一定程度的存储能力扩展的同时，通过只允许单点写机制避免分布式事务问题（从而保证强一致），通过多点读和 Shared-Disk 架构来实现一定程度的计算能力扩展。如此，在绝大部分客户业务需要的范围内（数据量小于 100TB，写入 QPS 小于 10W）可以实现存储能力扩展、计算能力扩展和数据强一致三者兼顾。

更为重要的是 Aurora、PolarDB 这种计算和存储分离的架构，为云数据库架构的演进提供了全新的想象空间。一旦实现计算和存储分离，将持久化数据放到分布式文件系统，上层计算节点无状态。仔细思考，我们发现目前数据库面临几个主要问题都能够得到很好的解决：

1.容量问题

分布式文件系统天然将给数据库提供更大存储容量。存储的数据量大后，性能如果遇到瓶颈，则瓶颈必然出现在网络上（分布式文件系统将数据分块打散到多个存储节点，规划得当的话，存储节点本地磁盘 IO 不会存在性能问题，而网络将成为瓶颈）。此时，可以利用 RDMA 、100Gbps 网卡等技术构建高性能网络解决网络的延迟和吞吐量问题。

2.性能问题

计算和存储分离后，计算性能和存储 IO 性能均可以水平弹性扩展，有效解决目前大部分 OLTP 业务遭遇的读性能问题。

3.容灾问题

数据层的容灾下放到分布式文件系统，这利用了分布式文件系统在容灾方面成熟的能力；计算层的容灾则可利用 Docker 编排技术，实现根据灾难情况，对计算节点进行灵活和弹性的编排。

4.价格问题

基于分布式文件系统可实现对存储的按需计费，基于 Docker 编排技术可实现计算节点的弹性伸缩，最终可根据业务存储量和访问量，实现按需付费，构建颠覆性的数据库计费模式。

5.运营成本问题

传统数据库机型需要兼顾 CPU、内存和存储密度，机型不容易选择，造价高。计算和存储分离后，计算层和存储层机型配置可以分别优化。计算节点选择 CPU 密集型机型，存储节点可选择低配 CPU 存储密集机型，机型搭配更为科学，运营成本进一步优化。

6.运维问题

一些棘手的运维问题将得到解决。比如大数据量备份和数据库迁移问题，由于分布式文件系统中数据分块存储，备份/迁移时可并行复制，大大降低了数据备份/迁移时间。

7.安全问题

计算和存储分离后，持久化数据都在分布式文件系统中，可以围绕分布式文件系统对数据做更细致的安全等级控制。

快速和弹性，是公有云最重要的两个价值点，也是云数据库重要的两个价值点。计算和存储分离天然贴合这两个价值点，必然是未来数据库架构发展的统一方向。最后给出一个云数据库 2.0 下的两地三中心方案，遥望下未来云数据库架构的简洁和优美：

一套架构多种定制：对外需求支持多样化

如上所述，计算和存储分离后，云数据库产品可以基于一套架构来满足用户目前的多种需求，解决多种问题。但云数据库 2.0 的进化，并不满足于此。我们还可以基于这一套架构去做更多定制，来满足云数据库 1.0 时代满足不了的用户需求。随着公有云数据库运营经验的加深，我们发现这种定制化的需求和计划越来越多。限于篇幅，下面举两个实际的例子来做说明：

例一 异构数据库

在大型机构的 IT 系统（比如电子政务云）中，由于历史和行政区划的原因，不同的子系统往往选择不同的数据库产品（Oracle、SQLServer、MySQL 等），从而导致数据库的异构。传统模式下，数据库异构导致不同子系统无法平滑分享其他子系统的数据，极大影响了 IT 系统的效率。虽然可以通过 ETL 等手段在异构的数据库之间保持数据的实时同步，但毕竟不是底层数据库完全打通，一些要求实时和强一致的需求无法满足。另外，ETL 的方式有额外的开发量和成本，且需要针对 IT 系统需求专门定制，不可大规模推广。

在云数据库 2.0 时代，计算和存储分离为数据库异构问题的解决，打开了想象空间。完全可以基于一套底层存储，在上面叠加不同类型的数据库实例来实现一套存储、多种接口访问（Oracle 接口、MySQL 接口、PG 接口等）的异构数据库。如此，各种业务无需修改任何代码，均可迁移到云数据库上，极大降低客户使用数据库的成本。

异构数据库理论上的一种实现方式是将各种数据库的 SQL 解析、查询优化、执行计划生成等模块，单独提取出来形成定制的数据库模块，而 SQL 经该模块处理后，将转换成统一的执行计划去调用同一个计划执行器，由执行器负责操作底层存储。当然，最终实现并不局限于这种方式，随着云数据库 2.0 的继续发展，我们相信在这个方向上将会有越来越多创意和产品出现。

例二 密文数据库

传统客户不愿意上云很重要的一个原因是数据的安全性，即数据不被任何其他方包括公有云厂商获取。如果能够将数据加密后上传到公有云数据库，而公有云数据库对加密后的数据又具备和明文数据等价的计算功能，那么这个问题将迎刃而解。

学术界已就该问题产生了理论上的解决方案，包括安全多方计算、同态加密等。但受限于算法的复杂度和性能原因，无法运用于工业环境。但只要怀着一份为客户服务的心，办法总会有的。在等待学术界进步的同时，云计算界也不应该袖手旁观，而应该积极地组合工业可用的算法和技术，构建切合用户实际的产品，满足用户需求。

UCloud 即将发布的安全屋下一个版本就很好地体现了这份用心。安全屋下一版将提供一个大数据交易的理想环境。交易双方可以把各自数据上传到安全屋，利用安全屋提供的分析套件，将自有数据和对方数据连接起来做一个联合分析，挖掘出对方数据的价值点，然后进行议价和交易。

普通的做法是交易双方把数据明文上传到安全屋。如此虽然能够满足需求，但留给客户一个最大的顾虑：数据是否会被云厂商或第三方窃取？为解决这一问题，安全屋联合 UDB 团队，专门开发出密文数据库系统，允许用户对数据进行加密后上传到安全屋，且在安全屋中对加密的数据进行和明文等效的计算，从而妥善解决这一问题。

密文数据库系统采用的核心方法包括保序加密、加密沙箱、SQL 解析和拦截等技术，均为目前技术上较成熟、工业上可运用的技术，很好地兼顾了产品创新和工业使用两个方面。

我们试图通过这个案例来说明云数据库 2.0 时代，基于客户需求定制的巨大潜力和价值。安全屋 0.4 版的密文数据库只是通向云数据库安全理想境界的一小步，未来在安全包括其他方面，必将大有可为。

深度学习：数据库运维智能化

如果说在线运行的数据库系统是一台高速运行机车的发动机，那么 DBA 的工作就是把这台发动机维护好。为高速机车维护核心的发动机部件体现了 DBA 工作的重要性。对于公有云数据库的 DBA 而言，工作不仅重要，更是繁重。 一般企业的 DBA 只需要为本公司数据库系统服务，而公有云 DBA 需要为上万家企业服务，工作量不言而喻。随着客户和数据库实例的增多，必须要通过自动化、智能化的方式来帮助 DBA 进行在线实例的维护，让 DBA 从繁重琐碎的日维护工作中脱离出来，把精力放在更高阶、更重要的事情上。

DBA 工作智能化的过程总的来说分为三个阶段：

1.原始的 DBA 手工运维阶段

2.DBA 重复性工作自动化阶段

3.DBA 工作智能化阶段

在原始的 DBA 手工运维阶段，DBA 凭借自己的经验借助一些半自动化的工具，完成云端数据库实例的日常运维、故障分析和解决、性能调优工作。

在 DBA 重复性工作自动化阶段，云数据库团队将建设体系化和自动化的 DBA 运维系统，收集数据库实例各层面的系统状态和性能数据，构建数据分析平台进行数据分析，判断或预判有问题或有潜在问题的数据库实例，以及通过预设规则进行数据库故障的处理、防范或告警。

在 DBA 工作智能化阶段，将利用大数据分析和机器学习的一些技术去进一步增加 DBA 自动化运维系统。比如，细时间粒度的数据库实例异常预警、数据库故障自动诊断和处理等。

结语

通过公有云为用户创造比传统 IT 更大的价值，这是 UCloud 云数据库团队对本职工作最核心的理解。云计算和公有云的高速发展最根本的原因不在于有多前沿的技术、多便宜的价格，而是在于通过一个个产品和功能的创新和创造，不断产生新的用户价值，在真实用户需求的助推下发展壮大。在连接用户和计算力的云计算 1.0 时代如此，在通过技术推动公有云产品内生进化的 2.0 时代也是如此。

通过上一篇文章和本文，我们试图将 UCloud 云数据库产品和云数据库团队的工作做一个全景式的描述，初步介绍 UDB 产品现有的能力、过去的经验、和对未来的思考。后续还会推出一系列文章，深入到产品技术细节和用户案例来探讨 UDB 容灾、分布式数据库 UDDB 、UDB 读写分离中间件的更多细节，敬请期待。

本文转载自公众号 UCloud 技术（ID：ucloud_tech）。

原文链接：

https://mp.weixin.qq.com/s/pDpgA_IdGrvjwyVfvKIcdw