UCloud分布式数据库UDDB:产品理念 | U刻
  • UCloud分布式数据库UDDB:产品理念

    栏目:产品动态

    前言

    在上一篇文章中, 我们介绍了UCloud分布式数据库 UDDB 的六大功能特性。这六个功能特性,看似涵盖不同方面,各自解决不同的问题,但却有一根主线贯穿其中。这根主线,就是UDDB自立项以来所秉持的产品理念:基于用户痛点、复用成熟技术来构建实用型的分布式数据库解决方案。

    所以,UDDB 以使用广泛的数据库中间件为基础,利用公有云的云端优势,解决数据库中间件的使用痛点;并加入互联网团队所擅长的微创新,扩展数据库中间件的使用边界,通过不断迭代,持续提高对业务的支持度。

    最终的目标,是构建一个如同单机数据库一样对业务友好,运行稳定,而又方便管理和运维的分布式数据库,有效解决 UCloud 客户在使用单机数据库时遇到的容量和性能问题。

    UDDB 的这个产品理念,简单几句话,即可讲清楚,本来无需赘述。但是,分布式数据库,偏偏是一个规则未定,都在摸着石头过河的领域。十几年来,各种产品百花齐放,但始终没有出现一个终结方案。在用户看来,也有一种乱花渐欲迷人眼的感觉,同时, 还伴随着分布式数据库到底选哪家好的纠结。

    UCloud 云数据库团队,对于分布式数据库该如何做,有自己的清醒的思考。这种思考,浓缩在 UDDB 的产品理念里,也体现在 UDDB 的产品细节当中。但是,在目前喧闹的分布式数据库圈里,除了静下心来做产品,也需要有一篇文章,把我们的思考更全面地呈现,方便 UCloud 的客户,了解 UDDB 产品的内在逻辑,把握 UDDB 的发展脉络,从而利于项目的技术选型,以及 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 三者只能满足两者),经济学领域有蒙代尔三角(本国货币政策的独立性,汇率的稳定性,资本的完全流动性不能同时实现,最多只能同时满足两个目标)。而在数据库研发领域,我们也可以定义这样一个三角:

    %e7%ac%ac1%e8%8a%82_%e6%95%b0%e6%8d%ae%e5%ba%93%e4%b8%89%e8%a7%92

    对业务的支持度: 即数据库产品的功能,能否对业务提供有效的支持。数据库产品功能越丰富,则业务开发就越简单。

    工程实现复杂度:即研发这款数据库产品的难度。工程实现复杂度越高,则开发周期就会越长,不稳定因素和bug量也会越多。而对于数据存储类产品而言,一个bug对业务的影响,可能是灾难性的。

    硬件要求: 这款数据库产品对硬件的要求。对硬件的要求越低,则业务系统的造价越低,越容易被客户接受。

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

    Oracle成功之道

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

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

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

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

    分布式数据库的三角难题

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

    %e7%ac%ac4%e8%8a%82_%e5%b0%8f%e9%a9%ac%e6%8b%89%e4%b8%8d%e5%8a%a8%e5%a4%a7%e8%bd%a6

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

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

    %e7%ac%ac2%e8%8a%82_%e5%88%86%e5%b8%83%e5%bc%8f%e6%95%b0%e6%8d%ae%e5%ba%93%e9%9a%be%e9%a2%98

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

    %e7%ac%ac3%e8%8a%82_nosql

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

    %e7%ac%ac3%e8%8a%82_nosql

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

    基于数据库中间件来做分库分表和读写分离,是除了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繁琐流程中解放了出来。把中间件技术搬到线上,让中间件上云,也贴合这一发展脉络。

    %e7%ac%ac6%e8%8a%82_uddb

    结语

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

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

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

    UDDB 已经于2016年11月13号,结束公测正式上线,目前部署机房包括北京B、D以及广东B。欢迎有需求的客户前来体验和使用。UDDB 团队希望能够和您深入交流业务的需求,和业务在分布式数据存储上遇到的问题。