01|什么是分布式数据库?
文章目录
你好,我是王磊,你也可以叫我 Ivan。
在这门课的第 1 讲,我想和你探讨一个最基本的问题:什么是分布式数据库?
回答这个问题,其实就是在给分布式数据库下定义。
分布式数据库和很多技术概念一样,没有权威机构来做这个定义,甚至对于哪些机构是权威机构,我们都很难有共识。
作为技术人员,我们常会提到一个概念,叫“事实标准”。当一个技术产品占据市场的主导位置时,它自然就成了同类产品的事实标准。例如,对于关系型数据库,可以说 Oracle 就是事实标准,因为所有数据库产品发布新版本时,都要拿自己的特性去和 Oracle 比一比。
很遗憾,分布式数据库作为一个新兴的基础软件,还没有一款产品占据“事实标准”的位置。既然没有参照,我们就自己动手,一起来定义分布式数据库这个概念吧。
由表及里、由外到内是人们认识事物的普遍规律,所以我们让也从内外部两个视角来观察。
外部视角:外部特性
外部视角,就是看看分布式数据库具备哪些特性,能解决什么问题。
通常,业务应用系统可以按照交易类型分为联机交易(OLTP)场景和联机分析(OLAP)场景两大类。OLTP 是面向交易的处理过程,单笔交易的数据量小,但是要在很短的时间内给出结果,典型场景包括购物、缴费、转账等;而 OLAP 场景通常是基于大数据集的运算,典型场景包括生成个人年度账单和企业财务报表等。
OLTP 与 OLAP 两种场景有很大的差异,所以很难在一款产品中完全满足两者的需求,因此在单体数据库时代就演化出了两个的不同技术体系,也就是两类不同的关系型数据库。向分布式架构演进后,两者在架构设计上也采用了完全不同的策略,很难在一个框架下说清楚。
所以,为了让你有更好的学习体验,在这个课程中,我们先专注于讨论 OLTP 场景下的分布式数据库。
说到这里,我想和你统一一下概念,如果没有特别说明,这个课程中出现的“数据库”都默认为“关系型数据库”,分布式数据库也都是指支持关系模型的分布式数据库。这就是说,NoSQL 不是我们要讨论的核心内容。
你可能会说,NoSQL 也很重要呀,MongoDB 多火呀。
NoSQL 当然很重要,MongoDB 确实也在一些细分场景中取得了成功。但是,从整体看,关系型数据库由于支持 SQL、提供 ACID 事务保障,显然具有更好的通用性,在更广泛的场景中无法被 NoSQL 取代。这一点通过 NoSQL 十余年的发展已经被证明。
事实上,分布式数据库的目标正是融合传统关系型数据库与 NoSQL 数据库的优势,而且已经取得了不错的效果。
定义 1.0 OLTP 关系型数据库
仅用“OLTP 场景”作为定语显然不够精准,我们来进一步看看 OLTP 场景具体的技术特点。
OLTP 场景的通常有三个特点:
- 写多读少,而且读操作的复杂度较低,一般不涉及大数据集的汇总计算;
- 低延时,用户对于延时的容忍度较低,通常在 500 毫秒以内,稍微放大一些也就是秒级,超过 5 秒的延时通常是无法接受的;
- 高并发,并发量随着业务量而增长,没有理论上限。
我们是不是可以有这样一个结论:分布式数据库是服务于写多读少、低延时、高并发的 OLTP 场景的数据库。
定义 2.0 + 海量并发
你可能会说这个定义有问题,比如 MySQL 和 Oracle 这样的关系型数据库也是服务于 OLTP 场景的,但它们并不是分布式数据库。
你的感觉没错,确实有问题。
那么,相对于传统关系型数据库,分布式数据库最大的差异是什么呢?答案就是分布式数据库远高于前者的并发处理能力。
传统关系型数据库往往是单机模式,也就是主要负载运行在一台机器上。这样,数据库的并发处理能力与单机的资源配置是线性相关的,所以并发处理能力的上限也就受限于单机配置的上限。这种依靠提升单机资源配置来扩展性能的方式,被称为垂直扩展(Scale Up)。
在一台机器中,随随便便就能多塞进些 CPU 和内存来提升提性能吗?当然没那么容易。所以,物理机单机配置上限的提升是相对缓慢的。
这意味着,在一定时期内,依赖垂直扩展的数据库总会存在性能的天花板。很多银行采购小型机或大型机的原因之一,就是相比 x86 服务器,这些机器能够安装更多的 CPU 和内存,可以把天花板推高一些。
而分布式数据库就不同了,在维持关系型数据库特性不变的基础上,它可以通过水平扩展,也就是增加机器数量的方式,提供远高于单体数据库的并发量。这个并发量几乎不受单机性能限制,我将这个级别的并发量称为“海量并发”。
听到这里你可能还要追问,这个“海量并发”到底是多大呢,有没有一个数字?
很遗憾,据我所知并没有权威数字。虽然理论上是可以找一台世界上最好的机器来测试一下,但考虑到商业因素,这个数字不会有什么实际价值。不过,我可以给出一个经验值,这个“海量并发”的下限大致是 10,000TPS。如果你有相关的经验,也欢迎你在评论区留言,我们一起讨论。
现在,基于这些理解,我们可以再得到一个 2.0 版本的定义:分布式数据库是服务于写多读少、低延时、海量并发 OLTP 场景的关系型数据库。
定义 3.0 + 高可靠
这个定义你觉得满意吗?
其实,这个 2.0 版本仍然有问题。
是不是没有海量并发需求,就不需要使用分布式数据库了呢?不是的,你还要考虑数据库的高可靠性。
一般来说,可靠性是与硬件设备的故障率有关的。
与银行不同,很多互联网公司和中小企业通常是采用 x86 服务器的。x86 服务器有很多优势,但故障率会相对高一些,坊间流传的年故障率在 5% 左右。
一些更加可靠的数据来自 Google 的论文Failure Trends in a Large Disk Drive Population,文中详细探讨了通用设备磁盘的故障情况。它给出的磁盘年度故障率的统计图,如下所示:
可以看到,前三个月会超过 2% 的磁盘损坏率,到第二年这个数字会上升到 8% 左右。
你可能会说,这个数字也不是很高啊。
但你要知道,对金融行业的关键应用系统来说,通常是要求具备 5 个 9 的可靠性(99.999%),也就是说,一年中系统的服务中断时间不能超过 5.26 分钟(365*
24*
60*
(1-99.999%) ≈ 5.26)。
而且,不只是金融行业,随着人们对互联网的依赖,越来越多的系统都会有这样高的可靠性要求。
根据这两个数字,我们可以设想一下,如果你所在的公司有四、五个关键业务系统,十几台数据库服务器,磁盘数量一定会超过 100 个吧?那么我们保守估计,按照损坏率 2% 来算,一年中就会碰到 2 次磁盘损坏的情况,要达到 5 个 9 的可靠性你就只有 5.26 分钟,能处理完一次磁盘故障吗?这几乎是做不到的,可能你刚冲到机房,时间就用完了。
我猜你会建议用 RAID(独立冗余磁盘阵列)来提高磁盘的可靠性。这确实是一个办法,但也会带来性能上的损耗和存储空间上的损失。分布式数据库的副本机制可以比 RAID 更好地平衡可靠性、性能和空间利用率三者的关系。副本机制就是将一份数据同时存储在多个机器上,形成多个物理副本。
回到数据库的话题上,可靠性还要更复杂一点,包括两个度量指标,恢复时间目标(Recovery Time Objective, RTO)和恢复点目标(Recovery Point Objective, RPO)。RTO 是指故障恢复所花费的时间,可以等同于可靠性;RPO 则是指恢复服务后丢失数据的数量。
数据库存储着重要数据,而金融行业的数据库更是关系到客户资产安全,不能容忍任何数据丢失。所以,数据库高可靠意味着 RPO 等于 0,RTO 小于 5 分钟。
传统上,银行通过两种方法配合来实现这个目标。
第一种还是采购小型机和大型机,因为它们的稳定性优于 x86 服务器。
第二种是引入专业存储方案,例如 EMC 的 Symmetrix 远程镜像软件(Symmetrix Remote Data Facility, SRDF)。数据库采用主备模式,在高端共享存储上保存数据库文件和日志,使数据库近似于无状态化。主库一旦出现问题,备库启动并加载共享存储的文件,继续提供服务。这样就可以做到 RPO 为零,RTO 也比较小。
但是,这套方案依赖专用的软硬件,不仅价格昂贵,而且技术体系封闭。在去 IOE(IBM 小型机、Oracle 数据库和 EMC 存储设备)的大背景下,我们必须另辟蹊径。分布式数据库则是一个很好的备选方案,它凭借节点之间的互为备份、自动切换的机制,降低了 x86 服务器的单点故障对系统整体的影响,提供了高可靠性保障。
令人兴奋的是,这种单点故障处理机制甚至可以延展到机房层面,通过远距离跨机房部署。如此一来,即使在单机房整体失效的情况下,系统仍然能够正常运行,数据库永不宕机。
至此,我们得出一个 3.0 版本的定义,分布式数据库是服务于写多读少、低延时、海量并发 OLTP 场景的,高可靠的关系型数据库。
定义 4.0 + 海量存储
还有没有 4.0 版本呢?
你猜的没错,我们还要补充一些存储能力的变化。
虽然单体数据库依靠外置存储设备可以扩展存储能力,但这种方式本质上不是数据库的能力。现在,借助分布式的横向扩展架构,通过物理机的本地磁盘就可以获得强大的存储能力,这让海量存储成为分布式数据库的标配。
最后,我们终于得到一个 4.0 终极版本的定义,分布式数据库是服务于写多读少、低延时、海量并发 OLTP 场景的,具备海量数据存储能力和高可靠性的关系型数据库。
内部视角:内部构成
只通过外部视角来看分布式数据库,已经足够了吗?其实,具有相同的外在特性和功效,未必就是同样的事物。
举个例子,哥白尼刚提出“日心说”来反驳“地心说”的时候,要用到 34 个圆周来解释天体的运动轨迹;而 100 多年后,开普勒只用 7 个椭圆就达到了同样的效果,彻底摧毁了“地心说”。从哥白尼到开普勒,效果近似,简洁程度却大不一样,这背后代表的是巨大的科学进步。
因此,讲完分布式数据库的外部特性之后,我们还要从内部视角来进行观察。
事实上,为了应对海量存储和海量并发,很多解决方案在效果上跟我们 4.0 版本的定义很相似。但是,它们向用户暴露了太多的内部复杂性。在我看来,对用户约束太多、使用过程太复杂、不够内聚的方案,不能称为成熟的产品。同时,业界的主流观点并不认为它们是分布式数据库,所以我们这门课也就不重点讨论了。
为了让你看清其中的差别,我将这些方案简单地分类介绍一下。
- 客户端组件 + 单体数据库
通过独立的逻辑层建立数据分片和路由规则,实现单体数据库的初步管理,使应用能够对接多个单体数据库,实现并发、存储能力的扩展。其作为应用系统的一部分,对业务侵入较为深。
这种客户端组件的典型产品是 Sharding-JDBC。
- 代理中间件 + 单体数据库
以独立中间件的方式,管理数据规则和路由规则,以独立进程存在,与业务应用层和单体数据库相隔离,减少了对应用的影响。随着代理中间件的发展,还会衍生出部分分布式事务处理能力。
这种中间件的典型产品是 MyCat。
- 单元化架构 + 单体数据库
单元化架构是对业务应用系统的彻底重构,应用系统被拆分成若干实例,配置独立的单体数据库,让每个实例管理一定范围的数据。例如对于银行贷款系统,可以为每个支行搭建独立的应用实例,管理支行各自的用户,当出现跨支行业务时,由应用层代码通过分布式事务组件保证事务的 ACID 特性。
根据不同的分布式事务模型,应用系统要配合改造,复杂性也相应增加。例如 TCC 模型下,应用必须能够提供幂等操作。
在分布式数据库出现前,一些头部互联网公司使用过这种架构风格,该方案的应用系统的改造量最大,实施难度也最高。
看过这三种方案,我相信你能够明白,它们共同的特点是单体数据库仍然能够被应用系统感知到。相反,分布式数据库则是将技术细节收敛到产品内部,以一个整体面对业务应用。
我猜,看到这里你一定很想知道,分布式数据库的内部架构到底长什么样呢?它跟这三种方案有什么区别呢?回答这个复杂的问题,就是我们这门课的使命了。这里你也可以先记下自己的答案,等学完这门课以后再回过头来做个对比,也是对自己学习效果的一种检验。
小结
好了,以上就是今天的主要内容了,我们来小结一下。
我们通过逐层递进的方式,勾勒出分布式数据库的六个外部特性,分别是写多读少、低延时、海量并发、海量存储、高可靠性、关系型数据库。
同时,也存在一些与分布式数据库能力近似的解决方案,这些方案的不足之处是都需要对应用系统进行一定的改造,对应用的侵入程度更深;其优势则在于可以最大程度利用单体数据库的稳定可靠,毕竟这些特性已经历经无数次的考验。
最后,我想就分布式数据库的名称做一些延伸。
“分布式数据库”在字面上可以分解为“分布式”和“数据库”两部分,代表了它是跨学科的产物,它的理论基础来自两个领域。这同时也呼应了产品发展的两条不同路径,一些产品是从分布式存储系统出发,进而增加关系型数据库的能力;另外一些产品是从单体数据库出发,增加分布式技术元素。而随着分布式数据库的走向工业应用,在外部需求的驱动下,这两种发展思路又呈现出进一步融合的趋势。
思考题
在准备分布式数据库这门课的过程中,有的朋友建议我讲讲 Aurora,但其实 Aurora 和这里说的分布式数据库还是有明显差别的,所以没有纳入正式课程。你了解 Aurora 或者它的同类产品吗?你觉得它和我所说的分布式数据库之间的差异是什么?那导致这种差异的原因又是什么呢?
欢迎你在评论区留言和我一起讨论,我会在答疑篇回复这个问题,如果感兴趣的同学很多,说不定会有加餐哦。
最后,如果你身边也有朋友对如何定义分布式数据库这个概念有困惑,欢迎你把今天这一讲分享给他,我们一起讨论。
文章作者 anonymous
上次更新 2024-04-14