日前，“UCloud用户开放日”***期活动顺利举行。UCloud关系型存储研发部经理罗成对系统梳理了UCloud数据库产品UDB的发展历程，并阐述了贯穿其中的产品设计理念，包括产品族介绍、架构设计、未来规划以及典型用户案例。
UDB产品的前世今生
UDB是UCloud于2013年1月正式推出的第三款产品，***先支持的是应用最广泛的MySQL数据库。经过五年的发展，UDB产品线越来越丰富，目前已广泛支持业内主流数据库，如MySQL、MongoDB、PostgreSQL以及SQL Server，产品特性包括主从架构、高可用、数据库专区、跨区高可用、读写分离、弹性扩展、备份与恢复、监控与告警等。
UDB产品非常适用于“三高”场景 —— 高性能、高可用、高并发，满足多行业的业务需求，包括游戏、电子商务、企业服务、O2O、在线教育等。和UDB一同成长起来的客户在上云之初就将UDB作为***。2014年，《刀塔传奇》在AppStore排行榜连续几个月***冠军，部署使用UDB后，高峰时期同时在线支持超过4000个实例，还不包括从库，整体发展非常迅速，UDB良好地支持了业务的发展。
UDB产品设计理念
UDB发展至今，贯穿其中的产品设计理念归结起来有两点：
◆ 用户需求驱动
UDB整体发展都紧跟用户的需求，不断进行产品更新、迭代;
◆ 产品自然进化
云数据库从字面上看是“云+数据库”，部署在云平台上，也会跟随着云平台的发展而不断成长。
一个好的互联网产品的定义是：通过可行的技术创造以及可持续发展的产品能力，满足用户需求。
UCloud一直都秉持着的信念是“用户需求就是我们的下一个产品”，这里的需求有两个层面：
◆ 功能性需求
对于数据库产品来说，它核心要解决的功能性需求是数据存储、数据访问安全。我们的理解是，数据放在这里，它怎么去落地、访问、读写、保证数据安全可靠，这是基本的功能性需求。
◆ 附加性需求
附加性需求包括稳定、容灾、容量、性能、性价比、可运维等。
云数据库产品，首先要满足用户的功能性需求，再一步步满足用户的附加性需求，这是UDB的产品设计理念。
UDB的产品演进之路
云数据库UDB发展了好几年，需求层次从简单到复杂，整个产品的演进也从简单到复杂，其背后的驱动力可从内外两个方面来看：
◆ 外驱动力
外驱动力，是说用户接入使用数据库后，用户本身的成长促使UDB产品不断进化，以满足其新需求。比如，前面提到的《刀塔传奇》，使用UDB后体量迎来爆发性增长，达到一定程度之后，需求层次也发生了变化，已经不再局限于一些功能性需求，后面对一些附加性需求就越来越多了。
◆ 内驱动力
内驱动力，也就是说基础设施在变化，给UDB提供基础设施的是UCloud云平台，基础设施越来越便宜，云平台的能力是不断进步的。另外一方面，性能更强劲、更具性价比的计算/存储硬件不断面世，也促使UDB汲取硬件价值，转移到产品上。
这些内外驱动力共同推动云数据库的快速发展，纵观整个UDB发展史，可以说经历了三重境界：
云数据库1.0可以简单理解为“云+数据库”，在云上部署了一个数据库。云有按需计价、快速交付、弹性扩容、高速网络、多可用区、虚拟化等一系列特点，而数据库本身解决了数据的结构化存储、标准化访问、数据安全性等问题。可以说，云跟数据库结合起来已能很好的满足用户功能性需求与部分附加性需求。
关于未来数据库的发展，云数据库已不再是简单的“云+数据库”，而是“云×数据库”，功能更像是矩阵式进化。现在业界比较关注的AWS Aurora DB就非常典型，它是RDS发展到一定阶段之后，克服了许多挑战，不断自我迭代，进化出的新一代产品，更好地覆盖了用户更高级的需求。目前来讲，个人认为Aurora DB很好地代表了数据库2.0的阶段。
UDB用户案例解析
之前说到，UDB非常适用于“三高”场景，下面结合真实案例为大家解析UDB是如何应用于这些业务场景的：
应用场景之业务持续可用
应用场景之高性能
应用场景之弹性扩容
应用场景之高性价比
◆ 应用场景之业务持续可用
我们做过一个调研：如果客户开始使用的是单点数据库，一旦宕机，现场更换硬件短则需要几分钟，长则需要几个小时，而且这种因宕机导致业务不可用的情况，后果是非常严重的。
UDB则通过一个简单、实用、可靠的基础架构解决了上述问题，它包括一个代理节点、主数据库、备数据库。
这种架构的优点在于：
1） 足够简单，因为它的组件比较少。架构设计上，UDB一直奉行“简单即可靠”。
2） 节点可以分布在不同的可用区，可以满足跨可用区的容灾需求。
通过主备模式，任意一个组件都有主备、热备，因此可以做到两层容灾：DB容灾和Proxy容灾。下图介绍了DB数据容灾，DB容灾原先VIP代理的是一个主库，进行容灾时则代理备库，非常简单。
另外一个是Proxy容灾，进行VIP跨可用区漂移，在VPC2.0的网络架构下，可以直接从可用区1漂到可用区2。
以金融和保险行业为例，金融行业因安保限制，需要“两地三中心”架构。UCloud的两地三中心解决方案首先在北京机房建一个主库，使用跨可用区的高可用产品，同时在上海有个备库，中间通过UDPN网络专线打通，结合UDTS数据传输产品，可进行可靠的、持续的数据传输，这样就能做到“两地三中心”需求。
互联网用户也有“两地三中心”的需求，将网络UDPN打通之后，从库能跟主库自然进行同步。只要把主从关系建立好，网络打通，自然就能在这3个可用区进行地域级容灾能力。MongoDB的两地容灾方案更为简单。
◆ 应用场景之高性能
使用数据库最容易出现的瓶颈就是I/O。普通DB面对I/O密集型的应用非常被动，集中表现为DB反应慢，紧接着的并发症是网络延迟增高、慢查询增多、连接数增多，雪崩效应很容易把DB打垮。
UCloud提供了一个解决方案——高性能SSD机型，底层采用PCI-e和NVMe SSD，其I/O能力吞吐量非常大。如果它对于性能要求更高，则推荐使用独享实例，这样可以使用整台整机，不会跟别人产生I/O的竞争；如果要求再高，那推荐分布式数据库UDDB，不仅容量可以扩展，性能也可以弹性扩展。典型客户包括互联网、游戏、电商、社交这些对于I/O要求特别高的用户。统计数据显示，高性能SSD UDB已经是不少用户重要业务的***。
在单节点性能无法满足业务需求的情况下，UCloud提供读写分离解决方案，完全可以做到性能成倍扩展。顾名思义，读写分离就是“读”和“写”分开，“写”可以放在一个节点上，“读”可以放在其他从库上，基础架构图如下：
UCloud有一位做在线K歌APP的用户从自建数据库迁移到UCloud云平台上，当时用户的数据库因业务增长迅速，遇到了性能瓶颈，使用了这套读写分离方案之后，其性能成倍扩展，用户使用“1主带5从”的架构，吞吐量可增长到6倍，不仅吞吐量上去，连接数也可以上去。因此，通过读写分离，业务将不再受单点连接数限制，也不再受单点容量的限制，可以平行扩展数据库吞吐能力，连接数上去，并发能力就越来越强了。
◆ 应用场景之弹性扩容
互联网应用有“起量很小，爆发很快”的特点。这些应用对云平台的弹性扩容能力要求很高：首先，底层基础架构必须具备弹性扩展能力，从应用层来讲，后端无状态的服务非常好做弹性扩展，但DB是有状态的；其次，是存在热点应用，也就是说整个DB都是为了这个应用在服务，就容易把整个DB拖垮。
随着业务的不断发展，某应用平台后端的单点数据库起初承受巨大的压力。在UDB上，数据库架构一步步从MongoDB Primary单点，到高可用副本集，再到分片集群演进，抗住了业务增长的压力。数据量与分片个数成线性比例增加。
举个例子，某家排行榜Top 10的社交应用APP，其业务可能达到一年30亿条数据量的增长，这还是比较保守的估计。该APP希望能有一款弹性扩容，业务兼容性好且性价比优的解决方案。当时，该应用已经每天有***的数据量，查询已经走了索引，简单的SQL优化对其来讲并不能提升太多。
UCloud推荐的解决方案是UDDB。
这个方案有几个优势，非常满足这款社交应用APP的需求：
弹性扩容：应对数据增长只需添加UDB节点，将新产生的数据写入新的节点；
静默扩容：扩容操作100%不影响业务；
按需付费：业务上线前期，仅需购买1个节点，存储未来3个月数据，如果业务快速增长，再添加节点，避免前期投入过大；
业务高度兼容： 客户业务程序仅改动2条SQL。
◆ 应用场景之高性价比
有些客户业务涉及到海量数据存储，比如物联网场景，部分智能终端一天的数据采集量就有几亿规模。数据采集上来需要存储并保留较长时间（比如3个月）。在面对这种高并发、数据持续写入的情况时，UDDB方案也能很好的满足客户需求。
针对类似场景，如果采用物理机自建，隐性投入很大，UCloud推荐高压缩UDB+数据库专区解决方案，能很好地降低数据库成本。由于数据库专区具有独享性，这样可以把整台机器的利用率提升，专区的整机具有更大存储空间，另外可以按时间滚动重用。同时进行DB压缩之后，即使是普通数据盘也能满足客户需求，因为物联网应用大量冷数据。***达到的效果是整个数据库的规模压缩比在3.2倍左右，数据量由原先150TB减少到目前52TB，总体成本节约26%。
UDB的未来展望
从UDB产品负责人的角度，对UDB未来的期待是——消除用户对数据库获得和使用的门槛。现在，获得门槛已经消除，用户可以方便地在线购买云数据库。
随着UDB产品逐渐成熟和完善，用户只需做一些编排工作，后端应用就可以直接用起来，而不必关注太多后端技术细节。但这还不够，在云数据库获得门槛已基本解决的形势下，降低使用门槛还要做很多努力。因此，今后要实现更多产品功能与特性来支持用户业务，将用户完全从数据库“解放”出来。
