云数据库 UDB 的三重境界「下」

构建功能网：全方位覆盖客户需求

云数据库发展第一阶段的目标，是把取代自建数据库 这个价值点做透，创造出区别于传统方式的全新价值。在第二阶段，则需紧扣用户使用数据库的痛点，有针对性地推出公有云解决方案，构成一张功能网， 全方位覆盖用户需求。

我们把第二阶段用户的痛点需求，归结为三类：

a.高可用和容灾：
数据库的高可用，即数据库节点容灾机制。它通过节点冗余和主备切换，在部分节点出现异常的情况下，保证数据库仍可正常提供服务。数据库的高可用是大型 IT 系统的必备机制，但不少系统在建设时，受限于自身基础设施和能力，无法实现优质可靠、高等级的数据库高可用。

而这一点，恰好是公有云的优势。首先是基础设施完善。公有云厂商拥有大量的数据中心，数据中心之间通过跨可用区，乃至跨地域的光纤专线进行连通，构成一张覆盖全国乃至全球的高性能网络。第二，公有云的规模效应将带来成本优势，能够显著降低基础设施的建设成本；最后，规模效应也让技术团队被超大力度地锤炼，技术能力和运营水平不断提升。基于以上三点原因， 公有云是实施数据库高可用的天然优质土壤。

因此，UCloud 基于自身基础设施来构建高可用数据库产品，为用户提供易获取、低成本、高等级的数据库高可用能力，自然也是题中之意，是 UDB 团队必须做透的一个目标。

b.容量和性能：
近些年的一个明显趋势，是全社会各行业的数据量在高速增长。原因之一，是全社会生产和生活日益互联网化，由此造成用户使用 IT 产品的次数和频率有数量级的增长；原因之二，在于企业对数据的价值越来越加以重视，普遍希望能够沉淀数据，分析数据，从数据中挖掘出价值。

数据库系统，作为 IT 系统的发动机，必然随着大数据时代的到来，遭遇新的挑战。用户使用 IT 产品频次的增加，必然在性能上，对数据库系统构成挑战；而全社会数据量的大规模增长，必然在存储容量上， 为数据库系统带来挑战。如何应对这两大挑战，且 总体保持 IT 成本可控，是用户越来越痛的问题。对于云数据库团队而言，也是创造全新用户价值的大好机会。

c.运维和安全：
运维和安全，是云数据库研发和运营永远的课题。需要围绕用户需求构建运维闭环，从数据导入导出、数据库运行期管理 /问题排查，到性能分析、数据库优化，让用户不使用任何第三方运维工具，即可将云数据库运维工作全部搞定。在安全上，除了 DBMS 自身的用户访问控制机制之外，还应该围绕审计、加密、防恶意攻击等方面，为用户提供优质的产品或功能，构建数据库安全运营闭环。

下面将展开介绍 UDB 产品围绕高可用、容量和性能、运维和安全三方面，构建的众多功能点。这些功能点和功能点的组合，构造出一张大网，全方位覆盖用户需求。

a. 高可用和容灾

以上用一个表格，概括介绍了 UDB 高可用各功能点。但不能概括的，是表格背后 UDB 团队对高可用的潜心专研和精心打磨。总的来说，UDB 团队对高可用这个价值点的打磨，包括以下几个方面：

1.MySQL 数据库内核深度优化

经过 MySQL 官方和社区多年的打磨，MySQL 软件在在可靠性和性能上表现优秀，达到了工业级别的数据库管理系统要求，在各个行业都有大规模的应用。

但对于 UDB 团队来说，在线维护几万个 MySQL 实例的稳定运行，迫使我们对 MySQL 的可靠性、容灾能力和性能提出更高要求。为此，UDB 团队对 MySQL 数据库内核做了深度优化，来进一步锤炼 MySQL 软件的品质。

这些优化包括： 1、改进半同步复制机制 2、解决复制的临界事务问题 3、提升主从复制的 IO 性能 4、消除复制机制中的文件锁竞争问题

限于篇幅，不展开对内核优化的论述，更详细的内容请见： http://mp.weixin.qq.com/s/NzXuXRKEUJjudx6vpSv5Gg

2.全面的容灾能力

高可用 UDB 的总体架构图如上，在容灾能力的建设上，需要考虑到两个层面。

MySQL 节点的容灾：
利用成熟的代理软件 HaProxy 作为代理网关来转发 SQL 请求，主数据库节点出现异常时，由 HaProxy 将 SQL 请求切换到从节点。HaProxy 成熟的节点健康检查和切换机制，能够及时有效地检查数据库节点异常，并进行切换。

HaProxy 节点的容灾：
所谓高可用，必须是系统内全部模块去单点，为此也需要考虑 HaProxy 的容灾。普通的做法，是利用 KeepAlived 等节点健康监测和故障处理软件，来实现多 HaProxy 节点的部署和容灾。但在长期的工业生产环境中，人们发现 KeepAlived 存在误检测和脑裂等问题，存在一定的稳定性隐患，不满足云平台容灾的需求。 为此，UDB 团队自研了针对 HaProxy 节点的健康检查和容灾系统，来充分保证高可用 UDB 的稳定性和容灾能力。HaProxy 健康检查和容灾系统，采用多节点、跨可用区部署，节点之间通过分布式一致性算法进行选主，结合 UCloud SDN 的 Vip 漂移能力，能够在单可用区完全不可用的情况下，实现 HaProxy Vip 的及时准确漂移，确保 UDB 实例的高可用。

b. 容量和性能

在上一篇文章提到，去年某技术博客公布了国内三大云数据库产品的评测结果，UDB 性能超出竞品数倍。时隔一年后的一个偶然机会，UCloud 云数据库团队得到一份数据库性能测试报告（报告获取地址：https://pan.baidu.com/s/1cm5VCM）。根据这份报告，我们对比测试了 UCloud 分布式数据库 UDDB 的性能，以此来分析一年过后，各云厂商在分布式数据库的性能差距。

从这个结果我们看到：以该份官方发布测试报告为基准，对比测试 UCloud 分布式数据库 UDDB，我们相对竞品，UDDB 依然保持 2-3 倍的性能优势。这也充分说明了物理机+Docker 架构的在性能上的强大优势，也体现 UDDB 中间件强劲的性能。

UDDB 测试环境如下：

c. 运维和安全

UDB 产品全景图

经过一，二阶段的发展，UDB 产品已经成长为基础扎实、品类完善、功能全面的一个云数据库产品体系。结合上篇第一阶段的 UDB 产品全景图， 叠加 UDB 团队在第二阶段做的工作， 得到新阶段的全景图如下：

在第一阶段的基础上，UDB 产品围绕用户使用云数据库的痛点需求，构建了三个方面的能力：

1.高可用能力
基于全球数据中心间的高速网络， 结合数据库软件自身的数据复制机制，以及自研的容灾检测、处理能力，不同级别的数据库高可用能力得以构建。包括：同机房高可用、跨机房高可用、跨地域高可用、两地三中心高可用，以及跨机房跨地域从库。

2.容量和性能问题解决方案
提供读写分离、分布式数据库两大产品，有效解决用户在数据高速正在下遭遇的数据库性能和容量问题。同时 TokuDB 压缩存储引擎提供很好的压缩率，在不损失性能的同时为用户节省数倍成本。

3.运维和安全
运维方面，提供面向 DBA 的数据迁移工具 DTS，以及面向开发团队，定位为开发人员身边的自动化 DBA 专家的 DBAMaster 产品。 在安全上，提供存储加密和数据库审计功能。

三位一体融合平台：云计算 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 产品面向未来的发展。

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

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

三者兼顾，现阶段依然是一个悬而未决的难题。但从近些年公有云上的新产品（ 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 下的两地三中心方案，遥望下未来云数据库架构的简洁和优美：

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

如上所述，计算和存储分离后， 云数据库产品可以基于一套架构，来满足用户目前的多种需求，解决多种问题。但云数据库 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 版的密文数据库，只是通向云数据库安全理想境界的一小步，未来在安全包括其他方面，必将大有可为。

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

如果说在线运行的数据库系统，是一台高速运行机车的发动机，那么 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 读写分离中间件的更多细节，敬请期待。