引言随着互联网的飞速发展，人类社会的数据量迅速激增，据统计目前人类一年产生的数据就相当于人类进入现代化以前所有历史的总和，而且互联网业务的发展通常具有爆发性，业务量很可能在短短的一个月内突然爆发式地增长几千倍，对应的数据也很可能快速地从原来的几百GB飞速上涨到了几百个TB。如果在这爆发的关键时刻，系统不稳定或无法访问，那么对于业务将会是毁灭性的打击。
这时，传统的单机数据库提供的服务，在系统可扩展性、性价比方面已不再适用。伴随着对于系统性能、成本以及扩展性的新需求，分布式数据库系统应运而生，力求突破单机MySQL容量和性能瓶颈，彻底消除单机数据库无法支撑企业业务高速发展的后顾之忧。在《关于分布式数据库，你需要知道的一些事》系列里，大U将以UCloud分布式数据库产品——UDDB为例，用三篇的篇幅为大家详细解析分布式数据库的一些重要特性和技术实践细节。
在《关于分布式数据库，你需要知道的一些事（中）》中， 我们介绍了UCloud分布式数据库 UDDB 的六大功能特性。这六个功能特性，看似涵盖不同方面，各自解决不同的问题，但却有一根主线贯穿其中。这根主线，就是UDDB自立项以来所秉持的产品理念：
基于用户痛点、复用成熟技术来构建实用型的分布式数据库解决方案。
所以，UDDB 以使用广泛的数据库中间件为基础，利用公有云的云端优势，解决数据库中间件的使用痛点；并加入互联网团队所擅长的微创新，扩展数据库中间件的使用边界，通过不断迭代，持续提高对业务的支持度。
最终的目标，是构建一个如同单机数据库一样对业务友好，运行稳定，而又方便管理和运维的分布式数据库，有效解决 UCloud 客户在使用单机数据库时遇到的容量和性能问题。
UDDB 的这个产品理念，简单几句话，即可讲清楚，本来无需赘述。但是，分布式数据库，偏偏是一个规则未定，都在摸着石头过河的领域。十几年来，各种产品百花齐放，但始终没有出现一个终结方案。在用户看来，也有一种乱花渐欲迷人眼的感觉，同时， 还伴随着分布式数据库到底选哪家好的纠结。
雾里看花的分布式数据库
技术的发展，有时候是以大踏步的方式，但有时候又迂回曲折。前者的典型，是智能手机和云计算技术，而相反的例子，就是分布式数据库。近十多年来，越来越多的业务，触到了单机数据库容量或性能的天花板，分布式数据库技术逐渐成为热门，业内开始了对分布式数据库的探索。但出乎意料的是，这次探索会经过从 SQL 到 NoSQL 再到 NewSQL 的一番折腾。十多年来，新的产品在如雨后春笋般涌现，但大多数最后悄无声息。不少用户为使用新产品付出代价，有些代价还比较惨重， 比如 Digg 的技术负责人John Quinn， 因为力挺 Cassandra 而丢掉了工作。
分布式数据库走过的这十多年， 确实给人一种雾里看花的观感。而分布式数据库的未来，也显得迷雾重重，充满不确定性。
比如，一年前业内还普遍认为，MySQL 无法实现节点间的数据强一致性，不少 NewSQL 以多节点强一致性功能为宣传点。但是今年 MySQL 低调推出了Group Replication，很好地实现了这一功能。在提振广大 MySQL 开发者和 DBA 信心的同时，MySQL 的此举，又让业界对 MySQL 是否能演进为通用型分布式数据库，充满遐想。
又比如，最近知乎上的比较火的，阿里 Oceanbase 和 AliSQL PK 事件。同一家公司，两个顶级的数据库团队，各自都埋头苦干多年，因为产品理念和发展逻辑的不同，最终难免一场内部厮杀。是 AliSQL 赢，还是 Oceanbase 更胜一筹？我想这也是一个有趣又充满不确定性的问题，阿里大可以开个盘口，让群众来下个注。
看不清时代的真相，往往是因为我们身处时代当中。正如黄仁宇先生评价中国近代史所说，“中国的革命，好像一个长隧道，须要101年才可以通过，我们的生命纵长也难过99岁”。对于分布式数据库的发展而言，我们可能也身处这样的一个隧道当中，一方面已经总结了过去的错误，另一方面还未能摸索隧道的尽头。
但技术的发展还是得奋力向前， 而 UCloud 也需要为客户提供，使用单机数据库达到容量或性能天花板时的解决方案。在做这个事情之前，延续着互联网团队的思辨传统，我们首先对过去十多年分布式数据库的发展过程，乃至过去三十多年来，关系型数据库的发展历程，进行了一次梳理，试图从中找寻做产品的一些线索。
数据库三角
如大家所知， 生活中经常有三个要求只能满足两个的情况。比如分布式系统领域有 CAP 理论（CAP 三者只能满足两者），经济学领域有蒙代尔三角（本国货币政策的独立性，汇率的稳定性，资本的完全流动性不能同时实现，最多只能同时满足两个目标）。而在数据库研发领域，我们也可以定义这样一个三角：
所以，才会需要有分布式技术，通过软件来整合一堆普通的服务器，达到一台超级计算机的效果。这是分布式数据库研发的一个大前提，即必须基于普通服务器和横向扩展的方式，来构建支持海量数据和访问的数据库系统。
有了这个前提，也就意味着在上述的数据库三角中，在硬件要求这一块，我们选择了普通服务器和横向扩展。但尴尬的地方在于，做了这个选择之后，要想在工程实现的难度 和对业务的支持度上做兼顾，就很难了。
对于 Google F1， Oceanbase，TiDB 等NewSQL产品， 它们选择了完全兼容 SQL 和事务，因此在工程实现上，就有高难度。不少棘手的问题需要解决，如节点间的数据强一致性，多表Join，分布式事务等。以 Oceanbase 为例，该项目于2010年立项，将近6年过后，尚未正式对外发布。而TiDB最近推出的技术文章讲到， TiDB光是测试用例，已经到600多万个，可见从头到尾实现一款数据库产品并做到工业强度，会是多么耗时费力的事情。
结语
用本文的数据库三角这个模型，来分析中间件上云这个事情，我们可以看到，选择中间件来做公有云上的分布式数据库，意味着选择了较为简单的工程实现复杂度，然后通过公有云这种互联网服务的快速迭代能力，和在线服务能力，以及从客户需求出发的微创新，不断的提高对业务的支持度，覆盖更多的业务。
UDDB 正是这个思路下的产品实践，也是 UCloud 云数据库团队，基于数据库中间件技术和公有云， 打造分布式数据库的一次探索。目前，这个探索还处于刚起步阶段，后面还有各种难题需要去解决，比如分布式事务、分布式 Join、查询优化等。
这个探索能否成功，一方面取决于团队自身的努力；另一方面，也取决于客户是否认可我们的理念，能够让 UDDB 团队有机会和客户一起，基于 UDDB 来做好业务的数据存储结构，解决业务的数据存储和处理问题，从而让 UDDB 获得打磨和成长。正如一位云计算的先驱所言：能做好云计算的，只能是云计算的客户，而云计算团队，只是在把对客户的支持做好。
—————— 以下是广告的分割线，一切为了KPI ——————
UCloud推出五大限量版冬日暖心礼盒，定制化满足不同场景的业务需求，最高可返3000元！
活动链接：用UCloud！3000元限量版礼盒等你来拆！
——————
关于分布式数据库，你需要知道的一些事（上）
关于分布式数据库，你需要知道的一些事（中）
本文由『UCloud关系型存储研发团队』提供。
关于作者 Robert（@robert），UCloud「应用云研发中心-结构化存储」研发工程师。毕业后从事数据库内核研发两年，之后混迹互联网多年，主要从事分布式后台系统的研发，目前专注在分布式数据库研发和运营工作。爱好足球、游泳，阅读，Bob Dylan和周云蓬的粉丝，锤子手机T1、T2的忠实用户。
「UCloud机构号」将独家分享云计算领域的技术洞见、行业资讯以及一切你想知道的相关讯息。
欢迎提问&求关注 oq～
以上。
