云数据库UDB的三重境界
前言
公有云服务本质上是用户和IT基础设施的连接器，通过打碎传统IT繁重的流程、低效的工作方式、不透明的价格以及糟糕的用户体验，重构出云主机、云数据库、云对象存储等产品，让用户更便捷地获取计算和存储能力，并保持使用习惯不变。
经过近十年的发展，一个越来越明显的趋势是公有云服务正从基于传统IT基础设施的包装和组合式创新，演进为围绕公有云场景、计算和存储能力的重新进化和升级。诸如容器云和Serverless架构、AWS Aurora云数据库、UCloud安全屋等，便是这一趋势的典型代表。
由此，我们可以对公有云的发展进程做一个两阶段的概括。云计算1.0的关键词是连接，通过互联网和公有云来连接用户和计算存储能力；而云计算2.0的关键词是进化，围绕公有云场景，重新看待全社会使用计算和存储资源的问题，对现有IT基础设施、模式做进一步的升级和进化。
站在云计算1.0向2.0进化和升级的档口，UCloud云数据库团队希望通过这篇文章梳理过去、剖析当下、想象未来，以此来全面展现UCloud云数据库服务（ UCloud DataBase Service，简称UDB ）能力，分享我们过去的经验和对未来的思考。
基因
考察一个云计算服务的发展犹如观察一颗种子落地后的生长。传统IT设施向云端变迁的趋势是云服务生长所需的阳光和雨露，但一颗种子能否长成参天大树，除了足够的阳光雨露，还要考察这颗种子的基因和成色。
在UCloud公司的四大价值观里，“客户为先”是放在首位的价值观。这体现了UClouders一以贯之的理念：只有为客户创造出真正的价值，企业才能够生存和发展。
创造真正的用户价值是UCloud所有产品的基因，也是UDB产品和云数据库团队的基因。对于UDB产品而言，创造真正的用户价值体现在两个方面：
需求驱动的产品研发和运营
需求驱动产品设计，技术评估实现可行性，必要时非标快速定制，定制逐渐沉淀为标准产品，整个过程循序渐进。小步快走，是互联网研发和运营的要领，也是公有云服务的要领。
以UDB跨地域跨可用区容灾为例，从单机版UDB开始，不断有用户因跨可用区容灾场景提出建跨机房从库的需求，中大型互联网客户尤为强烈。起初，以一种非标形式来提供能力的支持。后期因VPC 2.0上线，技术也愈加成熟，现已将这种非标能力转化为标准能力，即多可用区高可用UDB产品，同时也将UDB由可用区级提升为地域级，产品形态得到一次质的提升，传统模式下需要付出极高成本才能构建的异地容灾方案，通过UDB产品可以轻松获得，用户价值进一步被创造。
一切以客户价值为归依，匠心铸造真正价值
云计算产品是IT基础设施类产品，技术人员在云服务的研发中起主导作用。但技术并不直接等同于用户价值。即使再先进的技术，离真正的用户价值还是会有一段距离。这段距离则需要用做产品的匠心来来弥补。
所谓的产品匠心，非常重要的两点是对需求的洞察和对技术的取舍。技术人员常见的一个毛病是先入为主，将自己觉得酷的、牛的技术点等同于用户价值。但事实往往证明不一定。真正的用户价值创造，要打破技术人员思维的藩篱，洞察到用户需求的本质，从需求角度出发做技术选型，必要时敢于放下自己的喜好甚至利益，成就真正的用户价值。
以UDB产品的硬件架构选型为例。2013年UDB立项之初，并没有选择云主机方案，而是选择了物理机+ Docker的方案。如果基于云主机来构建UDB，能够充分复用云主机成熟的能力，UDB团队只需要关心硬件层面之上的问题，同时降低研发成本，快速推出产品。但在2013年我们判断，当时的云主机对IO的优化还存在不足。具体体现为IO路径过长，管理层次太多，这些都将影响IO性能和IO稳定性。而IO性能和稳定性，恰好又是云数据库最重要的两个技术指标。因此， UDB从一开始就选择了物理机+ CGroup的架构，在2014年全面转向Docker。事实证明，这是一个明智的选择。5年以来，在各公有云厂商的云数据库产品性能对比上，UDB每次都是完胜。
三重境界
王国维在《人间词话》二六节写到：古今之成大事业、大学问者，必经过三种之境界。“昨夜西风凋碧树，独上高楼，望尽天涯路”，此第一境也。“衣带渐宽终不悔，为伊消得人憔悴”，此第二境也。“众里寻他千百度，回头蓦见，那人正在灯火阑珊处”，此第三境也。此等语皆非大词人不能道。然遽以此意解释诸词，恐晏、欧诸公所不许也。
UDB的成长之路，也经历三个阶段，细分为三重境界。这三个阶段互相独立，又存在一个内在的逻辑，将它们牢靠地连接在一起。这个内在逻辑就是UDB的基因：创造真正用户价值。UDB在每一个阶段的萌芽、发展、跃迁，无一不是这个基因和理念在发挥作用。
1．做透一个点：取代自建数据库
UDB产品第一阶段要比拼的是能否比用户自建数据库（基于云主机或者自建IDC ），具备更大的用户价值。只有创造出更大价值，形成更高的价值势能，才能吸引用户将业务迁移到云数据库。所以UDB的第一个目标就是把“取代自建数据库”这一个点给做透。
2．构建功能网：全方位覆盖用户需求
过去几十年来，围绕DBMS出现了从容灾、迁移、安全到读写分离、数据拆分等解决方案和软件，对应用户业务的各种需求。这些解决方案和软件同样需要云化，并且需要利用公有云的优势产生比自建更大的价值。如此，才能不断强化云数据库的价值势能，服务好已有用户并吸引更多用户向公有云转化。
因此， UDB产品第二阶段要做的是构建一张云数据库功能网。在第一阶段的基础上，继续将用户需要的各个功能点做透。众多功能点以及功能点的组合，最终构成一张大网，全方位地覆盖用户的各种需求。
3．三位一体融合平台：云计算2.0下的内生进化
第一阶段和第二阶段，对新价值的创造都是基于成熟的软件或解决方案，利用公有云来实现功能的随手可得、快速部署和弹性扩展。这种模式清晰明确，但并不意味着云数据库价值创造的终点。
云计算2.0时代，公有云开始摆脱传统IT基础设施和软件的藩篱。在产品和技术上，围绕自身业务场景开启独立进化。其中，如何解决全社会大规模用云时的成本、效率和智能问题，是这场进化的核心。而UCloud云数据库团队也需要进一步去思考，是否能提供更加廉价优质、高效智能的云数据库产品。带着问题和思考， UCloud云数据库团队内部做了多次探讨，最终达成这样一个认知：云计算2.0下的云数据库服务，会是数据库PAAS化，运维智能化，以及结构化数据处理生态体系这样三位一体的组合。
下文我们将对做透一个点、构建功能网、三位一体融合平台展开详细介绍，用具体的例子来勾勒UDB发展的三重境界。
做透一个点：取代自建数据库
取代自建数据库，看来似乎简单，但逐一罗列并剖析需要考虑的五个价值点：
a．可靠性
b．稳定性
c．高性能
d．零维护
e．性价比
你会发现要做好绝非易事。 UDB产品经过几年的努力，完美地实现了做透一个点：取代自建数据库这一目标。
可靠性
云数据库的可靠性强调数据安全性包括两方面：一是DB数据；二是备份数据。DB数据落盘的持久性通常要求99.9999%及以上，表明数据保持存储状态不丢失的概率。此类数据主要是指用户存储在数据库中的数据，不包括缓存和临时存储。DB数据本地盘采用RAID10或者RAID50做好冗余，若是高可用机型，则再有实例级冗余。备份数据要求异地存储，多副本存储。
稳定性
这里强调的是单机稳定性。我们可以看下如何自建一套数据库，在数据中心的电力、物理网络、机架、物理服务器等基础设施之上，部署操作系统和补丁，安装数据库软件和补丁，运行数据库软件，启用数据库服务。如果是采用虚拟化部署，则额外涉及计算、网络、存储虚拟化。这是一套庞大的系统，各个环节都存在不可预知的故障风险。 UDB经过多年的运营积累了诸多经验，在多方面多层次保障其足够稳定。
高性能
如何通过软硬件结合使单机数据库的性能发挥到极致？高性能UDB机型底层采用PCI-E/NVMe SSD存储硬件，定制化宿主机Linux内核专门适配最新型硬件。采用自研IO调度算法，可良好保障实例级的IO隔离。数据库层面通过参数调优、内核定制优化，使数据库发挥出最优性能。通常情况下，数据库的性能瓶颈会出现在磁盘IO 。采用虚拟机自建存在诸多弊端，例如IO路径过长、IO稳定性较差、IO竞争等。UDB采用高性能物理机+Docker架构+自研IO调度算法，打造出强劲的IO性能，持续保障稳定性和隔离性。
零维护
通常情况下，数据库是后台服务框架里最为核心的组件，重要性不言而喻，日常运维工作慎之又慎。在第一个阶段， UDB提供的是数据库的全托管运维能力，包括一键部署、保活、容灾、备份、恢复、迁移、配置、漏洞修复、升级、监控与告警、巡检等等一系列的后台运维类操作，解放了客户的DBA人力/精力。本身在UDB产品上集成了上述多数的控制台操作，使客户对数据库基本可控。
性价比
客户对云数据库买不买账，性价比成为非常重要的因素。可靠、稳定、高性能、高可用、零维护等基础能力作为UDB的价值基础，在UDB产品上更是提供丰富的配置组合，自定义存储（普通盘or SSD盘）、内存大小、 VPC网络、可用区等，灵活多配，按需付费，一键交付。按业务增长，弹性扩容。客户完全省去自建数据库的一切环节，规划IDC，规划资源、采购、上架、交付部署以及后期一切运维工作。对于一些商业数据库（如SQL Server ）尤其划算，省去自购官方License费用。
构建功能网：全方位覆盖用户需求
云数据库发展第一阶段的目标是把“取代自建数据库”这个价值点做透，创造出区别于传统方式的全新价值。在第二阶段则需紧扣用户使用数据库的痛点，有针对性地推出公有云解决方案，构成一张功能网，全方位覆盖用户需求。我们把第二阶段用户的痛点需求归结为三类。
高可用和容灾
数据库的高可用是大型IT系统的必备机制，但不少系统在建设时，受限于自身基础设施和能力，无法实现优质可靠、高等级的数据库高可用。
而这一点恰好是公有云的优势。首先是完善的基础设施。公有云厂商拥有大量的数据中心，数据中心之间通过跨可用区，乃至跨地域的光纤专线进行连通，构成一张覆盖全国乃至全球的高性能网络；第二，公有云的规模效应将带来成本优势，能够显著降低基础设施的建设成本；最后，规模效应也让技术团队被超大力度地锤炼，技术能力和运营水平不断提升。基于以上三点原因，公有云是实施数据库高可用的优良环境。
容量和性能
大数据时代，全社会数据量在高速增长。原因之一是生产和生活日益互联网化，产生大量数据；原因之二是数据的价值越发得到重视，企业普遍希望能够沉淀并分析数据、从数据中挖掘出价值。
而传统的单机数据库系统，必然随着大数据时代的到来，在容量和性能上遭遇挑战。如何应对这两大挑战，且总体保持IT成本可控，是令客户越来越头痛的问题。
运维和安全
运维和安全是云数据库研发和运营永远的课题。需要围绕用户需求构建运维闭环，从数据导入导出、数据库运行期管理/问题排查，到性能分析、数据库优化，让用户不使用任何第三方运维工具，即可将云数据库运维工作全部搞定。在安全上，除了DBMS自身的用户访问控制机制之外，还应该围绕审计、加密、防恶意攻击等方面为用户提供优质的产品或功能，构建数据库安全运营闭环。
下面将列出UDB围绕高可用和容灾、容量和性能、运维和安全三个方面，构建的众多功能点。这些功能点和功能点的组合构造出一张大网，全方位覆盖用户需求。
高可用和容灾
容量和性能
运维和安全
UDB产品全景图
经过一、二阶段的发展，UDB产品已经成长为基础扎实、品类完善、功能全面的一个云数据库产品体系。UDB产品的全景图如下：
三位一体融合平台：云计算2.0下的内生进化
UDB产品在第一、二阶段的成长和发展是基于公有云场景，围绕成熟的数据库软件和解决方案来为用户创造使用价值。这种模式清晰明确，但也存在不少短板。
1．最大的问题在于传统的数据库软件的架构和代码已不适应公有云发展的需要。传统数据库在容量和性能提升、容灾、最新硬件的利用上都存在不足。
2．用户对云数据库提出的新需求，传统数据库已不能满足。比如按需付费、大数据量的高速备份、更短的灾难恢复时间、OLTP和OLAP融合、异构数据库等问题，传统数据库没有很好的解决方案。
3．数据库运维的方法仍然传统。当数据库实例和客户量达到一定的规模后，传统的人工运维的方法已变得不切实际。
我们不可能用产生问题的方式去解决问题。上述问题来源于传统的数据库架构和运维方式，因此不再可能用传统的方式去解决。唯一解决之道在于依托云计算2.0，实现云数据库的内生进化。摆脱传统模式的窠臼，开创云数据库的新境界。
在云计算从1.0向2.0跃迁的关键时间节点上， UDB团队提出未来发展的三位一体战略来刻画未来云数据库的技术和产品形态，满足未来客户的普遍需求：
a．数据库PAAS化
b．运维智能化
c．结构化数据处理生态体系
上述三个支点构成一个云数据库2.0体系，有力支撑UDB未来的发展。
数据库P AAS化
从用户使用的角度，IAAS和PAAS的区别在于，IAAS需要用户为租用的资源实例付费（即使资源没有被100%使用），而PAAS只需要为资源实际使用量付费。PAAS在IAAS的基础上，进一步降低了全社会IT使用成本，符合公有云发展的终极理想：让IT像水和电一样被人类社会使用。
像使用水和电一样使用数据库，这个理想看上去很美好，但很难实现。要做到像水和电一样使用数据库，必须解决两个关键问题：
1．容量和性能根据业务需求弹性扩展
2．存储和计算能力按实际使用量计费
第一个问题既目前热门的分布式数据库问题，而第二个问题长期以来只是一个模糊的目标，可望而不可及。但近几年来，计算和存储分离的架构理念，结合新型硬件或创新的数据库IO优化方法，为解决这两个问题带来希望。
计算和存储分离，就是将数据存储下放到分布式存储系统，数据库实例只保留SQL执行和事务处理等计算类操作，计算层和存储层通过网络交互彻底解耦。历史上，计算和存储分离架构的产品有存在（如腾讯云CDB第二代产品），但并未成为主流，其原因在于将计算和存储分离后，数据库的性能上不去，导致实际价值不大。但近几年来，业内分别从两个不同角度，突破了这一瓶颈：
1. AWS Aurora创造性地裁剪数据库内核，只落地RedoLog而不落地Page，从而减少了持久化数据的写入量，IO开销大为减少。
2．阿里PolarDB利用高速网络和新型硬件，优化了数据库内核的IO路径，实现了通过网络的分布式IO，和本地IO同样的延迟时间和更高的吞吐量。
由此，云数据库正式进入2.0时代，既计算和存储分离时代，向PAAS化开启大步演进。以AWS 2017年11月份推出的Aurora Serverless为例，目前已经做到了根据业务压力实现动态伸缩调配系统资源，存储能力和读写性能得以动态扩展；做到了根据业务实际数据量和读写QPS进行计费，从而实现像使用水和电一样使用数据库。
而UDB从2017年下半年开始，已经启动计算和存储分离架构的新一代数据库的开发，迈出构建UDB 2.0的关键一步，后续产品敬请期待。
运维智能化
一般企业的DBA只需要为本公司数据库系统服务，而公有云DBA需要为上万家企业服务，工作量不言而喻。随着客户和数据库实例的增多，必须要通过自动化、智能化的方式来帮助DBA进行在线实例的维护，让DBA从繁重琐碎的日维护工作中脱离出来，把精力放在更高阶、更重要的事情上。
DBA工作智能化的过程总的来说分为三个阶段： 1．原始手工运维；2．重复性工作自动化；3．结合机器学习的运维智能化。
在手工运维阶段， DBA凭借自己的经验借助一些半自动化的工具，完成云端数据库实例的日常运维、故障分析和解决、性能调优工作；
在重复性工作自动化阶段，云数据库团队将建设体系化和自动化的DBA运维系统，收集数据库实例各层面的系统状态和性能数据，构建数据分析平台进行数据分析，判断或预判有问题或有潜在问题的数据库实例，以及通过预设规则进行数据库故障的处理、防范或告警。
在DBA工作智能化阶段，将利用大数据分析和机器学习的一些技术去进一步增加DBA自动化运维系统。比如，细时间粒度的数据库实例异常预警、数据库故障自动诊断和处理等。
结构化数据处理生态体系
数据库PAAS化+运维智能化，这两个目标的实现，可以说实现了公有云数据库从业者一直以来追求的圣杯：一个根据业务压力自动弹性伸缩、按需付费且运维自治，仅需少数人工干预的云端结构化数据存储和处理平台，让用户真正得以向水和电一样使用数据库。但这还不够。
事实上，用户对结构化数据的存储和处理时复杂的，有时候还是非常个性化的。回顾对象存储PAAS平台的发展历程，一开始是解决文件的存取问题，随后开始提供对文件的加工处理能力（比如转码、压缩、鉴黄等），最后基于该平台结合其他技术（比如AI），进一步延伸诸如机器视觉、图像知识提取等功能，不断满足用户的需求。
因此，对于一个结构化数据处理PAAS平台而言，必然也需要随用户需求而动，不断向上生长，添加更多能力。更有必要的是打造一个开放的、共赢的结构化数据处理生态体系，引入全行业和全社会的力量，来建设一个拥有涵盖各行业用户需求，有着勃勃生机同时稳定可靠的结构化数据存储和计算生态系统，进一步解放全社会的生产力。
结语
通过公有云为用户创造比传统IT更大的价值，这是UCloud云数据库团队开展工作的出发点。云计算和公有云的高速发展最根本的原因不在于有多前沿的技术、多便宜的价格，而是在于通过一个个产品和功能的创新和创造，不断产生新的用户价值，在真实用户需求的助推下发展壮大。UDB推出5年以来，UCloud云数据库团队一直秉持这一理念，伴随云计算发展大潮经历三重境界，任凭岁月更迭而初心不改。
作者简介
Robert, UCloud资深数据库开发工程师
2007年毕业于华中科技大学数据库和多媒体技术研究所，曾先后在达梦数据库、腾讯从事过多年数据库内核和分布式后台服务的研发工作，目前专注于分布式数据库服务的研发和运营，UCloud UDDB产品和技术负责人。