<返回更多

分布式数据库,到底是个啥?

2023-08-08  IT168企业级  
加入收藏

1 啥是分布式DB?

 

随着TiDB等分布式DB的兴起,关系型DB也逐渐增加了分布式特性。在这些分布式DB中,数据分片和分布式事务是内置的基础功能,使业务开发人员能够像使用传统关系型DB一样简便地使用JDBC接口。作为一种分布式DB中间件,shardingSphere除了提供标准化的数据分片解决方案外,还实现了分布式事务和DB治理功能。让我们一起探索这些强大的工具如何提高数据管理和操作的效率!

事实标准

当一款技术产品占据市场主导地位时,它就成为同类产品的标杆。就像关系型数据库中,Oracle成为了事实标杆,因为所有新版本的数据库产品都要和Oracle进行对比,比较各自的特性。这样一来,Oracle就拥有更多的用户和支持,而其他竞争对手则需要不断改进自己的产品才能与之匹敌。

分布式数据库是一个新兴的基础软件,但还没有一款产品能够成为“事实标准”。我们需要自己来定义这个概念,因为没有现成的参考。为此,我们可以从内部和外部两个视角来观察它,这样可以更全面地认识它。

2 外部视角:外部特性

分布式 DB具备啥特性,能解决啥痛点。

业务应用系统按交易类型分类:

难有一款产品中完全满足两者,因此在单体DB时代演化出两个不同技术体系,即两类不同的关系型DB。向分布式架构演进后,两者在架构设计也采用完全不同策略,很难在一个框架下说清。

先专注讨论OLTP场景下的分布式 DB。本教程所提“ DB”都默认“关系型DB”,分布式DB也都指支持关系模型的分布式DB。即不讨论NoSQL,整体看,关系型DB由于支持SQL、提供ACID事务,具有更好通用性,在更广泛场景中无法被NoSQL取代。通过NoSQL十余年来发展已被证实。

分布式DB目标正是融合传统关系型 DB与NoSQL DB的优势,而且已经取得不错效果。

3 定义

3.1 OLTP关系型 DB

仅用“OLTP场景”作为定语显然不够精准,我们来进一步看看OLTP场景具体的技术特点。

OLTP场景的通常有三个特点:

我们是不是可以有这样一个结论:分布式 DB是服务于写多读少、低延时、高并发的OLTP场景的 DB

3.2 海量并发

你可能会说这个定义有问题,比如MySQL和Oracle这样的关系型 DB也是服务于OLTP场景的,但它们并不是分布式 DB。

相对传统关系型 DB,分布式 DB最大差异就是分布式 DB远高于前者的并发处理能力。

传统关系型 DB往往是单机模式,主要负载运行在一台机器。DB的并发处理能力与单机的资源配置是线性相关的,所以并发处理能力的上限也就受限于单机配置的上限。这种依靠提升单机资源配置来扩展性能的方式,即垂直扩展(Scale Up)。

在一台机器中,随随便便就能多塞进些CPU和内存来提升提性能吗?当然没那么容易。所以,物理机单机配置上限的提升是相对缓慢的。即在一定时期内,依赖垂直扩展的 DB总会存在性能的天花板。很多银行采购小型机或大型机的原因之一,就是相比x86服务器,这些机器能够安装更多的CPU和内存,可以把天花板推高一些。

而分布式 DB不同,在维持关系型 DB特性不变的基础上,它通过水平扩展增加机器数量,提供远高单体 DB的并发量。这个并发量几乎不受单机性能限制,我将这个级别的并发量称为“海量并发”。

“海量并发”到底多大

没权威数字。虽然理论上是可以找一台世界上最好的机器来测试一下,但考虑到商业因素,这个数字不会有什么实际价值。不过,我可以给出一个经验值,这个“海量并发”的下限大致是10,000TPS。

2.0版本的定义:分布式 DB是服务于写多读少、低延时、海量并发OLTP场景的关系型 DB

3.3 +高可靠

2.0版仍有问题。是不是没有海量并发需求,就不需要使用分布式 DB了呢?不是的,你还要考虑 DB的高可靠性。

一般来说,可靠性是与硬件设备的故障率有关的。

与银行不同,很多互联网公司和中小企业通常是采用x86服务器的。x86服务器有很多优势,但故障率会相对高一些,坊间流传的年故障率在5%左右。

一些更加可靠的数据来自google的论文FAIlure Trends in a Large Disk Drive Population,文中详细探讨了通用设备磁盘的故障情况。它给出的磁盘年度故障率的统计图,如下所示:

img

可以看到,前三个月会超过2%的磁盘损坏率,到第二年这个数字会上升到8%左右。

你可能会说,这个数字也不是很高啊。

但你要知道,对金融行业的关键应用系统来说,通常是要求具备5个9的可靠性(99.999%),也就是说,一年中系统的服务中断时间不能超过5.26分钟(365*24*60*(1-99.999%) ≈ 5.26 )。

而且,不只是金融行业,随着人们对互联网的依赖,越来越多的系统都会有这样高的可靠性要求。

根据这两个数字,我们可以设想一下,如果你所在的公司有四、五个关键业务系统,十几台 DB服务器,磁盘数量一定会超过100个吧?那么我们保守估计,按照损坏率2%来算,一年中就会碰到2次磁盘损坏的情况,要达到5个9的可靠性你就只有5.26分钟,能处理完一次磁盘故障吗?这几乎是做不到的,可能你刚冲到机房,时间就用完了。

我猜你会建议用RAID(独立冗余磁盘阵列)来提高磁盘的可靠性。这确实是一个办法,但也会带来性能上的损耗和存储空间上的损失。分布式 DB的副本机制可以比RAID更好地平衡可靠性、性能和空间利用率三者的关系。副本机制就是将一份数据同时存储在多个机器上,形成多个物理副本。

回到 DB的话题上,可靠性还要更复杂一点,包括两个度量指标,恢复时间目标(Recovery Time Objective, RTO)和恢复点目标(Recovery Point Objective, RPO)。RTO是指故障恢复所花费的时间,可以等同于可靠性;RPO则是指恢复服务后丢失数据的数量。

DB存储着重要数据,而金融行业的 DB更是关系到客户资产安全,不能容忍任何数据丢失。所以, DB高可靠意味着RPO等于0,RTO小于5分钟。

传统上,银行通过两种方法配合来实现这个目标。

第一种还是采购小型机和大型机,因为它们的稳定性优于x86服务器。

第二种是引入专业存储方案,例如EMC的Symmetrix远程镜像软件(Symmetrix Remote Data Facility, SRDF)。DB采用主备模式,在高端共享存储上保存 DB文件和日志,使 DB近似于无状态化。主库一旦出现问题,备库启动并加载共享存储的文件,继续提供服务。这样就可以做到RPO为零,RTO也比较小。

但是,这套方案依赖专用的软硬件,不仅价格昂贵,而且技术体系封闭。在去IOE(IBM小型机、Oracle DB和EMC存储设备)的大背景下,我们必须另辟蹊径。分布式 DB则是一个很好的备选方案,它凭借节点之间的互为备份、自动切换的机制,降低了x86服务器的单点故障对系统整体的影响,提供了高可靠性保障。

令人兴奋的是,这种单点故障处理机制甚至可以延展到机房层面,通过远距离跨机房部署。如此一来,即使在单机房整体失效的情况下,系统仍然能够正常运行, DB永不宕机。

3.0定义,分布式 DB是服务于写多读少、低延时、海量并发OLTP场景的,高可靠的关系型 DB

3.4 海量存储

虽然单体 DB依靠外置存储设备可以扩展存储能力,但这种方式本质上不是 DB的能力。现在,借助分布式的横向扩展架构,通过物理机的本地磁盘就可以获得强大的存储能力,这让海量存储成为分布式 DB的标配。

最后,我们终于得到一个4.0终极版本的定义,分布式 DB是服务于写多读少、低延时、海量并发OLTP场景的,具备海量数据存储能力和高可靠性的关系型 DB

4 内部视角:内部构成

具有相同的外在特性和功效,未必就是同样的事物。

“日心说”反驳“地心说”要用到34个圆周解释天体运动轨迹;而100多年后,开普勒只用7个椭圆就达到同样效果,彻底摧毁“地心说”。从哥白尼到开普勒,效果近似,简洁程度大不一样,这背后代表的是巨大科学进步。

因此,讲完外部特性,还要从内部视角观察。

为应对海量存储和海量并发,很多解决方案在效果上跟V4定义相似。但它们向用户暴露了太多的内部复杂性。用户约束太多、使用过程太复杂、不够内聚的方案,不能称为成熟产品。同时,业界的主流观点并不认为它们是分布式 DB。

来看分类:

4.1 客户端组件 + 单体 DB

通过独立的逻辑层建立数据分片和路由规则,实现单体 DB的初步管理,使应用能够对接多个单体 DB,实现并发、存储能力的扩展。其作为应用系统的一部分,对业务侵入比较深。

这种客户端组件的典型产品是Sharding-JDBC。

4.2 代理中间件 + 单体 DB

以独立中间件的方式,管理数据规则和路由规则,以独立进程存在,与业务应用层和单体 DB相隔离,减少了对应用的影响。随着代理中间件的发展,还会衍生出部分分布式事务处理能力。

这种中间件的典型产品是MyCat。

img

4.3 单元化架构 + 单体 DB

单元化架构是对业务应用系统的彻底重构,应用系统被拆分成若干实例,配置独立的单体 DB,让每个实例管理一定范围的数据。例如对于银行贷款系统,可以为每个支行搭建独立的应用实例,管理支行各自的用户,当出现跨支行业务时,由应用层代码通过分布式事务组件保证事务的ACID特性。

根据不同的分布式事务模型,应用系统要配合改造,复杂性也相应增加。例如TCC模型下,应用必须能够提供幂等操作。

在分布式 DB出现前,一些头部互联网公司使用过这种架构风格,该方案的应用系统的改造量最大,实施难度也最高。

共同的特点是单体DB仍能够被应用系统感知到。相反,分布式 DB则是将技术细节收敛到产品内部,以一个整体面对业务应用。

5 亚马逊的Aurora

和这里说的分布式DB有明显差别,了解Aurora或同类产品吗?和本文分布式DB差异在哪?为啥会有这种差异?

为啥说Aurora不是分布式DB?Aurora存算分离,使亚马逊云存储服务更高效、易使用。算是NewSQL中比较成功的了。

特点

Aurora是提出一种新的单体架构以减少网络IO和同步阻塞,逻辑上可以看做一个庞大的单体 DB,用分布式来支持容错和高吞吐量。:

但Aurora特点是Share storage,计算节点垂直扩展,存储节点水平扩展,写入性能收单机资源的影响。

投票机制

aurora也用到了,6个副本,半数以上就确认写入成功。但无分片,不能多写,肯定不算分布式。

不能多写(重点!),适用场景有很大区别,所以这是个重要标准。但因为Aurora是基于共享存储,所以说它是分布式也不是没道理。定标准只是为让学习思路清晰。

实际场景Aurora和分布式存储的应用的差别

Aurora还是关系型 DB,而分布式存储系统范围较广,比如HBase这样的分布式键值系统。两者在功能上有很大差异。

AWS aurora,阿里polarDB,腾讯CynosDB,华为的Taurus等产品都是类似架构:计算存储分离。所有计算节点都访问存储节点上的同一份数据,也可以说是分布式架构。这架构的局限是写入不能横向扩展,对很多小规模应用够了,所以不影响它取得商业成功。

阿里的PolarDB是分布式DB?它采用哪种方案?

PolarDB和Aurora架构类似,存算分离,计算节点垂直扩展,存储节点水平扩展。代表其写入能力有上限,但因简化了日志存储和其他一些优化,单点能力比普通MySQL强很多。

6 总结

逐层递进,勾勒出分布式 DB的六个外部特性:写多读少、低延时、海量并发、海量存储、高可靠性、关系型 DB。

也存在一些与分布式 DB能力近似解决方案,它们不足之处是都需要对应用系统进行一定的改造,对应用的侵入程度更深;其优势则在于可以最大程度利用单体 DB的稳定可靠,毕竟这些特性已经历经无数次的考验。

分布式DB的名称做一些延伸。

“分布式 DB”在字面上可以分解为“分布式”和“ DB”两部分,代表了它是跨学科的产物,它的理论基础来自两个领域。这同时也呼应了产品发展的两条不同路径,一些产品是从分布式存储系统出发,进而增加关系型 DB的能力;另外一些产品是从单体 DB出发,增加分布式技术元素。而随着分布式 DB的走向工业应用,在外部需求的驱动下,这两种发展思路又呈现出进一步融合的趋势。

7 FAQ

① 写多读少不应加入分布式DB的定义?

分布式DB服务写多读少应用,我觉得不管写多读多都可应用分布式,关键是单体承担不了这么多请求了(不论读写),所以高并发就够了,写多读少不应加入分布式DB的定义?

强调写多读少,是因为:

云dbms在分布式基础上,更关注计算存储分离后可独立扩展,甚至动态扩缩容,self-driven搞起来,更好卖了。这也引发不少问题,aurora类 DB提出log is database思想,降低写压力,snowflake通过建立中间分布式换存层,降低网络瓶颈等。

② 分布式DB V.S 分库分表

分布式关系型DB,感觉就是把客户端或中间件的方案直接作为DB服务端的特性组件,把分库分表做得更自动化?

最大区别在于:

③ MyCat这种怎么说?

随分布式DB发展,MyCat这类中间件市场会越来越小。当然,它的使用场景也可能转向对异构DB支持,就像Presto。

④ 都说互联网应用数据请求“读多写少”

所以有了一主多从读写分离、全量数据缓存等解决“读”问题的扩容手段。如果说的是同一个指标,是否意味着分布式DB不适合互联网应用?

互联网确实可通过一主多满足“读多写少”,但前提是对读对一致性要求低。而金融场景,很多读操作依然无法在备库运行,就是一致性不满足要求。所以,对互联网也不能一概而论,还是区分场景。

⑤ 交易场景下,交易代码配合分布式 DB而做出的交易补偿或者数据回放等

如需要交易代码配合做出补偿和回放,这很可能意味着它不是分布式DB。分布式DB成熟前,确有不少应用代码配合单体 DB。这类应用代码也会被抽离出来形成独立框架,如阿里SOFA。

⑥ Newsql落地如何?

如北京银行和光大银行都上线TiDB,Oceanbase也在南京银行落地。

⑦ BigTable算特殊的(代理中间件 + 单体 DB(分布式文件系统))吗?

毕竟靠Chubby作为一个中间层,不过数据的获取是直接与文件系统中交互完成。

BigTable是分布式KV系统,不属于分布式DB。因为这里所说的分布式DB是分布式架构实现的关系型DB。当然它底层依赖一个分布式文件系统,所以看上去也分两层,但职能和DB差别很大,建议关注PGXC风格分布式DB。

⑧ 基于OLAP使用场景的分布式关系型DB产品

最典型的MPP架构DB,如Greenplum和华为的GaussDB 200,内核都使用PostgreSQL。还有Vertica。OLAP不再强调事务支持,如果弱化对数据更新要求,很多大数据生态的产品都可纳入,如Clickhouse,Hive on spark,甚至Kylin都算是广义OLAP分布式DB。

关键词:分布式数据库      点击(7)
声明:本站部分内容来自互联网,如有版权侵犯或其他问题请与我们联系,我们将立即删除或处理。
▍相关推荐
更多分布式数据库相关>>>