数据库 频道

达梦分布式数据库演进

  作者:冯源

  整理:老鱼

  作者介绍:

  冯源,武汉达梦数据库股份有限公司副总经理,主要负责达梦数据库产品的软件测试、技术规划工作。长期从事大型、通用国产关系数据库管理系统——达梦数据库产品DMDBMS v4.0、v5.0、v6.0、v7.0和v8.0系列的产品测试和技术规划工作,熟悉国内外主流数据库产品体系架构,对于数据库安全防护体系、数据库性能优化、数据库领域基准测试模型与方法具有深厚经验;参与了《GB/T 30994-2014 关系数据库管理系统检测规范》、《GB/T 20273-2019 数据库管理系统安全技术要求》等多项国家标准的编制工作。

  正文

  我分享的主题是“达梦分布式数据库演进”,主要分享达梦公司分布式数据库演进、发展历程,介绍达梦公司对分布式数据库未来发展和应用前景的分析观点。

  在正式分享前,我想先从几个不太相关的小故事讲起,以归纳我的核心观点。

  无论是爆米花,还是要扔出去的手雷,亦或是过年发射的窜天猴,其实都有一定共性,就是加热膨胀时,如果不对其进行精准控制,扔出去就会变成一个炸弹,如果是在精准的温度、压力下释放,就会变成爆米花,如果自始至终都给其一个发泄口,就会飞上天去变成一个漂亮的焰火。

  通过这三个事物,我想表达的是什么?很多时候,看起来不太一样的东西背后,其实都有着相似的原理,不同的用途,就看你怎么用?

  技术是用来解决问题的,同样的技术可以解决不同问题。反之,为了解决问题,达到相同目标,又可以选择不同的技术,至于用什么技术、用哪项技术,还是以需求为核心,这是我在导语当中可以得出的两个结论。

  接下来,我将通过挖掘分布式数据库是怎么产生的,最初是为了解决什么问题,来印证前面两个结论。

  分布式数据库其实不是什么特别新鲜的东西,基于以下几个事实:

  为什么?上述事实可能不是特别清晰,回到当时文献看一看,这是1979年到1980年的文献。

  总体来说,当时学术界对于分布式数据库的研究,主要分为两个架构:一个是分层集中控制式,也就是很多区域性数据库,上面加一个分布式调度层。另一个是非集中控制式,这个更接近现在的分布式数据库,也就是去中心化的架构。即便是在今天来看,也不是特别过时,现在有很多数据库仍然是沿着这样的思路架构来做。

  无论任何一种架构,1970-1980年时,其定义,抽象出来有三个特点,也就是所谓的分布式数据库应该具备哪些特征?

  首先,是跨物理地域的特点,数据库实例分布在不同的物理地点。当时名词中,有一个“集群系统”,也是采用类似架构,由很多节点组成,但没有跨地域,所以,称之为集群系统。

  另一特点是局部自治性,任何数据库都应该具备本地管理、本地处理的能力。

  在此基础上有全局性的数据访问请求时,不需要关心数据分布在哪一个区域,称之为应用透明性。

  总结起来,就是物理上分布,逻辑上一体。

  当时的分布式数据库选的什么技术进行研究?我们能发现,其中很多词在今天是非常熟悉了,比如数据的划分,水平划分还是垂直划分,分片存储还是复制存储,数据分布以后如何保证事务完整性?怎么实现数据提交?怎么预防分布式环境下的变化?

  要用一项技术,一定要看当时的需求是什么?我们再仔细看,就会发现非常有意思的东西,今天我们谈数据库的划分,更多的是希望,通过数据库的划分让数据分散存储,提高数据存储能力,通过分散存储可以实现过载均衡性能提高,但当时的论文写得非常有意思,他们的目标是节省网络费用,甚至包括后面很多研究者在研究,到底是应该分片还是应该复制,或者是在什么时候分片、什么时候复制,出发点也是怎样平衡存储费用和网络通信费用。

  既然,分布式数据库的大量技术问题,早在“上古时代”就已经提出,并已有相当的基础,那么,为什么分布式数据库在90年代却“偃旗息鼓”了?

  如果仔细回顾当时研究这些技术的目标,也就是费用问题,就能够很清楚地知道,为什么出现这些情况。(左图)是当时西德实验室的分布式数据库,从当时的架构图非常清楚地看到,三所大学节点网络通信用的是电话线,九十年代,在家里上网都知道,那个时候上网费有多贵,所以,如果数据库系统,分布式通信依靠的是电话线实现,就近划分数据就近访问数据,一定能够节省大量的通信费用成本,如果不去挖历史,是无法得知当时的技术目标是什么。

  七八十年代,计算机应用刚刚兴起,那时,现在熟悉的中间件还不存在,用户稍微多一点,数据库就无法承担并发能力,在C/S模式下,硬件能力不足以支撑“较高并发”,因此,单机数据库或者集中式数据库没有办法满足性能要求。

  为什么在九十年代会发生这种巨变?原因很简单,硬件技术的发展,使得集中式数据库具备了足够的并发处理能力。另一个非常重要的原因是,交易中间件的诞生和完善,大概是1985年到1995年,它的出现改变了应用程序访问数据库的访问模式,信息系统从两层结构变成三层结构,显著改善了数据库并发响应速度。

  达梦认为,集中式数据库技术的发展,充分发挥了硬件设备的能力,当时面对的问题,最终由硬件设备的发展+集中式数据库组合解决,人们失去了继续发展、使用分布式数据库技术的理由。

  小结一下,通过对七十年代到八十年代分布式数据库的回顾,不管是用户或是研究者,在当时研究分布式数据库技术,或者到了九十年代不再研究分布式数据库技术,最终都是“需求第一” 性原则的作用结果。

  1989年,达梦发布了第二代数据库产品DM2(分布式数据库管理系统),也是那时,达梦开始做分布式数据库研究,体系结构、存储结构和随机查询方面都做了一些工作,最后,也是随着技术趋势的演进,演变为主要研发集中式数据库产品。

  到了今天为什么分布式数据库再次兴起?移动互联网之前,我们非常熟悉的甲骨文和IBM这些巨头,在市场上非常成功。而到2012年,以Google发布Spanner论文为标志,分布式数据库结束蛰伏。分布式数据库到今天有着非常多的流派,大体上可以分为三类:Google Spanner及其参考文献,PG XC/XL技术结构方案更传统,也更接近经典的分布式数据库,为什么我把PG单独拎出来说?因为,达梦看到,今年国内有很多分布式数据库厂商基于PG XC/XL,产业上是不可忽视的点。另外Amazon云原生数据库,国内也有很多产品是参照其方案实现。

  我们找到一些参考资料,只针对Spanner和Aurora进行了对比,我个人把PG也加进来了。可以看到,虽然大家都叫分布式数据库,但实际上细节不一样,这说明实现目标不一样。如果仔细去看的话,有的是共享存储架构,有的是非共享。今天,因为时间有限,我们单独拎出来一个点看一看,比如持续可用。为什么不同的分布式数据库会选择不同的数据库协议?强调一下,之前我形成的第一个结论,为了解决产品的问题,用户和开发人员都是以“需求第一性”原则为主。

  Spanner有很多的技术创新,最关键的精髓有几点:首先是引入PAXOS,引入TruTime API,然后,做了多版本的外部一致性。

  为什么Spanner要做PAXOS?Spanner是Google自用的数据库,虽然后来发布了Cloud Spanner,但在最初,它是给Google广告系统用的。Google是一个全球化的公司,业务遍布全球,用户遍布全球,分布式机构也是遍布全球,全球化的公司就有全球化的利益,什么叫做全球化的利益?就是当一个区域甚至一个大洲发生不可控的因素的时候,利益不会受损,业务可以持续运转,需要一个能够维护全球利益的数据库,也就意味着遇到局域性的灾害、疫情甚至政治不稳定、海底光缆故障大面积设备失效,也可以保证其业务持续不断地赚钱,也能为客户带去它的价值,这是Google对数据库的诉求。正因为如此,Google第一篇论文并非冠以分布式数据库,而是冠以全球分布式数据库的名字和原因。

  今天,我们发微信或打电话都时习以为常,认为信息传播成本非常低,可能就几分钱或者几毛钱话费,但我们忽略了一个事实,信息传播速度是有上限,信息传输是有成本的。

  站在地球这样个范围不是问题,如果极端一点,远在火星或太阳进行通信,一条消息发过去,要五分钟的时间,如何知道消息对方收到否?所以,通信天生的不可靠才是一种常态。

  只有在这种情况下,我们才会意识到,进行一次通信传输应该有一些保证,保证信息不可失真,保证大家能够看到同样的消息,在这种情况下PAXOS是最好的衍生性保障。

  为什么70年代会有分布式集群概念?因为距离比较近,如果距离远,信息能不能收到会成问题,我们是不是能达成共识也是问题,这是这个概念的由来,没有一个大距离的跨度,是不需要这么复杂技术的。

  众所周知,PG-XC/XL的经典版本,或社区版本当中用的是传统复制技术,保证同步复制和异步复制,好处是同步复制带来强一致,异步复制延迟较低,但这是在一个小距离环境下看到的,也就是一个硬币正面和反面的问题。要是这个距离扩大到一千公里级别,硬币的另外一面就会显现出来,在大区域范围下,同步复制的延迟以及异步复制带来的不一致性问题就会显现。PG这套系统如果视之为集群效果非常好,有着更好的响应时间、运维和线性扩展效果,所以,这套系统更适合小范围部署的、追求线性扩展的用户。

  云原生算不算分布式?有没有衡量标准?如果以是否产生分布式事务来看,单主模式是没有分布式事务的,所以不是分布式数据库。以有没有分布式存储来看,逻辑上看是共享存储,所以,好像也不算分布式数据库,但是基于云技术实现分布式存储,所以应该可以算分布式数据库。如果从有没有跨地域的能力来看,当然有了,所以应该算分布式数据库。

  因此,从需求第一性原则出发,云原生是不是分布式不重要,重要的还是Amazon为什么要做?Aurora的定位是什么?满足全球访问需求?其实不是,也不是在小范围做到极致扩展,就是为了租赁给普通用户。普通用户怎样使用数据库?99%的用户没有像Google那样的全球利益,也不需要做极致的扩展,其实就是一种使用模式,只是想把以前使用从本地搬到云上,简简单单地让云厂商解决副本的问题就很完美。

  所以我们能看到,过去几年,云原生数据架构的变革更多的是在中下层动刀,比如亚马逊的日志即数据,减少云上的网络流量,到了国内可能还有一些改变,Quorum协议改到Raft协议,进一步降低网络同步流量占用,但会引入一些延迟;不过这样也没关系,可以通过RDMA来弥补。另一方面,因为云上部署,因此基础设施集约化是可以做到的,NVME可以上,FPEG、RDMA也可以上,这些就是前几年可以看到的云原生数据库厂商的技术发展的内容,而数据库的中上层,更多的是以继承PG和MySQL为主。

  通过分析这三类技术路线,达梦认为是不是分布式其实并不重要,还是要回到发展技术的初衷来看“需求第一性”。站在用户的角度要不要用分布式数据库?怎样用分布式数据库?用户应该要对自己的需求非常清楚,然再去选数据库。

  刚才谈了三种架构,还有一种没有谈,就是分布式中间件。2015年,达梦做了一个分布式中间件,后来发现这个技术方案对应用不透明,事务也不保证,容灾能力也较弱,所以,达梦抛弃了这套方案,中间件的事情,交给中间件厂商来做,达梦来走适配,效果同样很好。

  到了2019年,达梦认为从现状上来看,分布式数据库最大的问题是兼容性代价太高,所以,达梦更提倡透明式TDD的概念,在保障数据库通用性、具有比较强的一致性前提下,同时具备一些可扩展的能力。

  到了2020年,达梦发布了新一代的原生数据库,希望在透明式分布式数据库的基础上进一步加强分布式处理能力。

  达梦分布式思路,原则是“需求第一性”,技术只是工具手段,按需选择。

  鉴于分布式数据库现状,众所周知,分布式数据库性能很强,但有好就有坏。达梦对未来的判断是,80%的系统架构还会在原有的传统集中式架构当中去用,因为这些业务系统负载较高,或者对可靠性要求没有那么高,并发也没有那么高,通过传统技术可以非常低成本地解决。

  随着分布式架构复杂度的增加,成本也一定会增加,所以,更适合更高端的行业场景。传统集中式无法解决的分布式数据库应该是什么样子?

  首先,是数据量爆炸,并发曲线非常陡峭,用户对数据响应时间的容忍度相对比较低,这也是一个现实,分布式数据库今后不是你的数据库或者是我的数据库,它将变成基础设施,因此一定要有足够的容灾能力,因为,大家都是跑在一个系统上。

  时间有限,每个需求采用什么样的技术来满足,不能全部介绍,我只提三点:达梦数据库已经引入Raft,因为异地副本自适应能力是采用传统复制技术不可能实现的,现在有很多厂商仍然采用一主多备的复制,达梦认为并不太适合1000公里以上的自适应故障处理能力。

  前几年,分布式数据库主要是谈架构,很少谈优化器,其实优化器是数据库的核心。作为一个传统的数据库厂商,做了这么多年,达梦最大的优势就在于优化器。记得以前和大家分析过一个案例,一个央企财务系统上,有一个500多页的SQL,达梦可以很好的处理这种复杂SQL,这种请求目前来看,在分布式是比较难处理的,而达梦可以把这种SQL优化能力,从集中式数据库平移到分布式数据库产品里面。

  目前,分布式数据库应用和推广最大的障碍就是生态,原因在于分布式数据库的通用性不够:很多经典功能在集中式可以用得很好,分布式就不能用,所以,会有很多的应用移植工作。达梦的重点思路是通过一套Code Base完成这项工作,不管是集中式还是分布式,达梦都用一套Code Base,无论是做运维管理还是应用开发,或是做大数据集中层,协议都是一样的,语法都是一样的,可以做到平滑的过渡、互联,实现统一。

  最后,目前看来分布式数据库技术现状,用一个字来总结就是“乱”,厂商多、路线多、概念多。但这是百花齐放的时代,乱是正常的。从长久来看,最终一定是趋同。不管是从传统厂商做起的达梦,还是从To B、To C或者服务器厂商做起的,没有谁一开始就是做分布式数据库的,大家的基因不太一样,但基因不是重点,重点是环境最后会把大家塑造成长得差不多的模样。所以,作为用户不用太担心,选谁都不会错。

1
相关文章