关于分布式数据库，你需要知道的一些事（下）

引言

随着互联网的飞速发展，人类社会的数据量迅速激增，据统计目前人类一年产生的数据就相当于人类进入现代化以前所有历史的总和，而且互联网业务的发展通常具有爆发性，业务量很可能在短短的一个月内突然爆发式地增长几千倍，对应的数据也很可能快速地从原来的几百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 三者只能满足两者），经济学领域有蒙代尔三角（本国货币政策的独立性，汇率的稳定性，资本的完全流动性不能同时实现，最多只能同时满足两个目标）。而在数据库研发领域，我们也可以定义这样一个三角：

• 对业务的支持度： 即数据库产品的功能，能否对业务提供有效的支持。数据库产品功能越丰富，则业务开发就越简单。
  
• 工程实现复杂度：即研发这款数据库产品的难度。工程实现复杂度越高，则开发周期就会越长，不稳定因素和bug量也会越多。而对于数据存储类产品而言，一个bug对业务的影响，可能是灾难性的。
  
• 硬件要求： 这款数据库产品对硬件的要求。对硬件的要求越低，则业务系统的造价越低，越容易被客户接受。
  

这三个要求互相独立，互不干扰，但都不可或缺。从历史上看，能够成功的产品，必然是能够很好地满足这三个要求，而失败的产品，往往是对三个要求中的一个或几个，缺少足够的支持。

Oracle成功之道

单机数据库时代，Oracle 等关系型数据库，能够在短期内迅速胜出，并称霸结构化存储和计算领域数十年之久，最主要的原因是它把这三个要求都很好地满足了。

首先，关系模型和 SQL，在业务对数据的访问的便捷性上，提供了无可比拟优势，业务程序不需要关心数据的存储位置，只需要在基于关系模型这个比较高阶的模型，写出 SQL 语句，即可对数据进行增删查改（以及很方便的事务控制）。

第二，高速发展的硬件产业（硬盘/内存/CPU），为关系型数据库提供了很好的硬件支持。 在Oracle成长的几十年当中，硬件行业的高速发展，总是能够先于用户的需求，提供更大容量、更高速度、更便宜的硬件资源，这就让 Oracle 的研发，不需要像现在一样考虑硬件不够用的问题，能够将产品目标聚焦在单机数据库上。 同时，即使用户数据规模有增长，对硬件需求量更大，由于摩尔定律的存在，在硬件上的支出并不会有对于的增长，从而在数据库软件上，就有足够的预算。可以说，Oracle 这款产品，充分吃到了20世纪60年代来以来，硬件发展的红利。

第三，关系型数据库的理论基础和工程基础，在产品刚起步的阶段，已经比较成熟。比如数据库的核心数据结构，B树早在50年代已经提出，而 SQL 相关的编译理论和技术，此时也有非常好的技术和人才储备。在 Jim Gray 等人于90年代左右解决事务问题之后，关系型数据库便进入了飞速增长的阶段，在各个行业都很好地得到了应用。

分布式数据库的三角难题

但是到了互联网数据和访问量大爆炸的时代，我们发现对于数据库来说，首先是硬件的红利没有了。在海量的数据量和访问量面前，目前运行在单机上的传统数据库，只是一个 “小引擎” ，根本无法容纳。虽然在现阶段，有些客户的业务，还可以通过性能强悍的小型机和大型机来扛一扛，但这些售价昂贵的机器，大多数公司也消费不起。

所以，才会需要有分布式技术，通过软件来整合一堆普通的服务器，达到一台超级计算机的效果。这是分布式数据库研发的一个大前提，即必须基于普通服务器和横向扩展的方式，来构建支持海量数据和访问的数据库系统。

有了这个前提，也就意味着在上述的数据库三角中，在硬件要求这一块，我们选择了普通服务器和横向扩展。但尴尬的地方在于，做了这个选择之后，要想在工程实现的难度 和对业务的支持度上做兼顾，就很难了。

比如 MongoDB，Redis 等 NoSQL 产品，它们选择了更低的工程实现难度，由此对业务的支持，则远不如SQL产品。比如Redis不支持多表Join，范围查询支持偏弱。而MongoDB需要手写Json指令去操作数据，编写复杂的查询，是一种痛苦的体验。

对于 Google F1， OceanBase，TiDB 等NewSQL产品， 它们选择了完全兼容 SQL 和事务，因此在工程实现上，就有高难度。不少棘手的问题需要解决，如节点间的数据强一致性，多表Join，分布式事务等。以 OceanBase 为例，该项目于2010年立项，将近6年过后，尚未正式对外发布。而TiDB最近推出的技术文章讲到， TiDB光是测试用例，已经到600多万个，可见从头到尾实现一款数据库产品并做到工业强度，会是多么耗时费力的事情。

另一种思路：数据库中间件技术

基于数据库中间件来做分库分表和读写分离，是除了NoSQL和NewSQL之外，另一种分布式数据库解决方案。典型的数据库中间件，有MySQL Proxy、DRDS、MyCAT、KingShard、OneProxy 等。它的两个主要功能，分库分表和读写分离，分别用来突破单机数据库的容量和性能瓶颈，过去十多年，在业内各领域，特别是在互联网领域里，有大量的应用。

分析这些数据库中间件的特点，我们看到，这种软件仍然是无法兼顾数据库三角中的三点要求，和 NoSQL 一样，它也是牺牲业务支持度，选择了比较简单的工程实现。不同的是它仍然以 SQL 作为访问接口，而不是另辟蹊径。可以说，数据库中间件是分布式数据库技术中的保守派，守定 SQL 这颗大树，基于业务需求修修补补发展到今天。

但是，这种保守的策略，却使得数据库中间件成为过去十多年，业内最主要的分布式数据库解决方案，使用中间件的项目，远多于使用 NoSQL 和 NewSQL 项目。对这一现象做进一步分析，我们总结出以下三大原因：

• 数据库中间件对SQL的支持，特别是SQL语法和MySQL、PG产品保持兼容，看似保守，却是非常务实。支持老的单机数据库接访问口，这就使得用户的学习成本低，业务系统的迁移更为方便。而NoSQL产品自创访问接口，到头来却出现各种复杂和问题，不但前期有额外的学习成本，后期功能复杂时，往往还达不到SQL的灵活支持。

• 数据库中间件复用成熟的数据库产品作为存储层，而自身是无状态的，只关心SQL的解析和路由，因此数据的可靠性得到保证，用户也更放心使用。而对于从头开发一款数据库产品，数据可靠性的保证，还是要经过一番锤炼的。

• 数据库中间件，相对于NoSql和NewSQL，还有一个优势是可以深度定制。 相对于Mongo，Cassandra 这样的大型产品，数据库中间件是轻量的，掌握其源代码的门槛，虽然有，但相对更低。这就赋予了IT公司根据业务需求，修改中间件源码，灵活应对业务增长和需求变化的能力。

UCloud的思考

作为业内领先的公有云计算厂商，UCloud 对分布式数据库有自己的思考。以 UCloud 目前的技术储备和研发能力而言，从头研发一款 NewSQL 产品，并不是太大的问题，但这不一定是能够给用户带来最大价值的做法。

一直以来，UCloud 的产品理念， 是客户的需求就是我们下一个产品。诚然，打造一款和单机数据库100%兼容的、高可靠、强一致、高可用、易扩展的 NewSQL 产品， 不管是从技术还是从产品角度去看，都是值得奋斗的目标，但这个目标是否就是 UCloud 用户的诉求，是值得思考的。深入考察客户的需求，我们发现中间件是最合适 UCloud 的分布式数据库解决方案。原因有这几个方面：

第一，时间不等人。

客户业务数据量的高速增长，急需分布式数据库的解决方案，而打造一款靠谱的 NewSQL 产品，则需要时间。一方面，存储产品本身的研发周期本身偏长， 另一方面，从业内的经验来看，目前并没有一款 NewSQL 产品，在公有云环境下得到大规模的使用（ AWS Aurora 只允许从一个节点写入，还不能称之为 NewSQL ），即使对于已经立项好几年的产品。在目前的时间节点投入去做一款 NewSQL ，则只能服务于几年后的客户，而用户当下或接下来的需求，则得不到满足，这并非 UCloud 愿意看到的。

第二，在调研时发现，不少遇到单机数据库瓶颈的客户，已经部署或者开始调研基于中间件的分布式数据库解决方案。

结合近十多年来，中间件在业内的推广使用情况，可以看出中间件确实存在巨大的价值。但是中间件方案存在三大问题：

• 部署和运维成本高。将中间件软件成功部署上线，线上顺利运行，需要一定的时间；同时 SQL 的路由规则，每次都需要人工配置，也就意味着每次增加新的库表，都需要做配置修改。

• 系统扩容复杂和高风险。使用中间件的分库分表功能，将业务数据划分到多个数据库节点。假如业务增长了，节点不够用，则需要水平扩容。水平扩容流程繁琐，代价高昂且高风险。涉及到数据迁移、业务停服、配置变更等一系列操作，需要极高的运维能力，任何一个环节出错，都有可能对业务造成重大影响。

• 功能扩展门槛高。假如你足够幸运，选定一款中间件后，这款中间件可以满足此后所有的功能需求，所有业务 SQL 都能够支持。但这并不容易。有时候由于业务的发展，你需要修改中间件代码，才能支持业务需求。而这个工作又有一定的门槛，需要深入理解中间件的代码，对 SQL 的语法，语义解析，乃至 SQL 语句优化，都需要有足够的了解。

这三个问题，恰好是公有云最擅长解决的。第一和第二个问题，本质上都是运维操作太复杂。而将运维操作自动化，是公有云的传统强项。可以将这些操作，简化成 WEB 页面提供给客户，点点鼠标即可完成运维和管理操作，将使用传统中间件时需要耗时几个月的工作，缩短到几小时甚至几分钟；

对于第三个问题，客户如果需要功能扩展，可以向公有云团队提需求，由专业的团队来负责研发、上线和维护，减少企业在这块的人力和时间投入。同时，公有云团队必然也有动力去改进产品，尽力做到功能的不断完善，对业务场景的覆盖不断增强，做到用户还没有需求时就提供相关功能。

回顾互联网发展历史，其发展的脉络之一，就是用连接和自动化的方法，把现实世界的难活、脏活、累活搬到线上，变成优质的在线服务。通过这种方式，支付宝在全国范围内建立了信用体系，而云计算则将运维从传统IDC繁琐流程中解放了出来。把中间件技术搬到线上，让中间件上云，也贴合这一发展脉络。

结语

用本文的数据库三角这个模型，来分析中间件上云这个事情，我们可以看到，选择中间件来做公有云上的分布式数据库，意味着选择了较为简单的工程实现复杂度，然后通过公有云这种互联网服务的快速迭代能力，和在线服务能力，以及从客户需求出发的微创新，不断的提高对业务的支持度，覆盖更多的业务。

UDDB 正是这个思路下的产品实践，也是 UCloud 云数据库团队，基于数据库中间件技术和公有云， 打造分布式数据库的一次探索。目前，这个探索还处于刚起步阶段，后面还有各种难题需要去解决，比如分布式事务、分布式 Join、查询优化等。

这个探索能否成功，一方面取决于团队自身的努力；另一方面，也取决于客户是否认可我们的理念，能够让 UDDB 团队有机会和客户一起，基于 UDDB 来做好业务的数据存储结构，解决业务的数据存储和处理问题，从而让 UDDB 获得打磨和成长。正如一位云计算的先驱所言：能做好云计算的，只能是云计算的客户，而云计算团队，只是在把对客户的支持做好。

—————— 以下是广告的分割线，一切为了KPI ——————

UCloud推出五大限量版冬日暖心礼盒，定制化满足不同场景的业务需求，最高可返3000元！

活动链接： 用UCloud！3000元限量版礼盒等你来拆！

——————

相关阅读推荐：

关于分布式数据库，你需要知道的一些事（上）

关于分布式数据库，你需要知道的一些事（中）

​本文由『UCloud关系型存储研发团队』提供。

关于作者

Robert（@robert），UCloud「应用云研发中心-结构化存储」研发工程师。毕业后从事数据库内核研发两年，之后混迹互联网多年，主要从事分布式后台系统的研发，目前专注在分布式数据库研发和运营工作。爱好足球、游泳，阅读，Bob Dylan和周云蓬的粉丝，锤子手机T1、T2的忠实用户。

「UCloud机构号」将独家分享云计算领域的技术洞见、行业资讯以及一切你想知道的相关讯息。

欢迎提问&求关注 o(*////▽////*)q～

以上。