文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

分布式数据库是不同的

2024-11-30 10:44

关注

关于分布式数据库与集中式数据库的不同,我上周已经发文讨论过了,今天我要讲的是另外一个问题,那就是不同的分布式数据库产品也是不同的。

2013年,我和一些准备开发一款分布式数据库的朋友在讨论这个产品的时候,实际上大家对数据库,特别是分布式数据库都不太了解。我们给这款数据库提出的目标是:

         

图片

首先是超大规模,都分布式数据库了,肯定是要能解决集中式数据库的容量不足的问题的,因此超大是必须的,超大规模的数据库可以解决存储容量、计算容量与超大规模计算的速度等一系列问题;可动态扩展,不够用了就扩节点;无需备份,自动容灾,自动故障切换;有了上面这一条,那么保证永远在线,永不出错也就不是难事了。不过实际上今天看来,当时对数据库的了解太粗浅了,十年过去了,我还没看到这个数据库产品出现。

目前的分布式数据库产品种类繁多,技术路线也各有不同,我今天不准备对其做准确的分类,而是从几个小角度来看看这些数据库产品之间的不同。首先是从存算分离和对等分布式这两种最为典型流派说起。分布式数据库要么采用存算分离架构,要么采用对等分布式架构。其典型产品就是TiDB和OceanBase。

存算分离,顾名思义,其计算引擎和存储引擎是完全分离的,计算引擎负责SQL的执行,存储引擎负责管理被存储的数据。彻底的存算分离的数据库,其最典型的特点是创建数据表的时候不需要SHARDING KEY,数据存储的分片是数据库内部自动管理的。当SQL引擎需要访问某个数据的时候,会根据元数据信息以及分片逻辑,自动找到所需要访问的数据。存算分离的数据库,计算节点可能只有一个,也可以是一个读写节点,多个只读节点,甚至也可以是多个全功能对等的读写节点。比如TiDB,其TiDB节点是计算节点,多个计算节点是对等模式的,全功能读写的。其TiKV是存储节点,负责存储所有的数据。

对于存算分离的分布式数据库,计算节点生成SQL的执行树后,会把算子下推到多个存储节点进行并行的数据扫描或者访问。算子的并行化程度以及能够下推的粒度决定了执行的效率。因此此类数据库的性能取决于SQL执行计划的水平与可下推的算子的粒度。

有些存算分离的数据库,其存储节点是一个独立的数据库实例,这种情况下,大部分算子是以子SQL的形式下推到存储节点的,其效率相对是较低的。当然,数据库厂商也可以就其数据库引擎的核心进行改造,使之能够接受更细小的算子的下推,从而提高执行性能。有些基于Postgresql等开源代码的分布式数据库,比如Gaussdb就是这么做的。

谈到Gaussdb,这里就多说几句,实际上Gaussdb是一种存算分离的分布式数据库,其CN是计算节点,DN是存储节点。不过Gaussdb与TiDB虽然说都是采用存算分离,但是其实现方式差异很大。Gaussdb的CN/DN实际上都包含了一个全功能的RDBMS实例,甚至客户端可以直接连接到DN上去做SQL的执行。而TiDB的计算与存储引擎的功能是完全分离的,必须二者合体才能完成SQL执行的任务。对于Gaussdb来说,一个SQL可以将其子查询全面下发到DN上,CN只做简单的汇聚,CN也可以下推更细粒度的算子到DN上,由CN完成更多的计算。基于Gaussdb的架构,如果我们要将一张表分布到多个DN上,那么我们就必须指定Sharding Key。

那么这两种存算分离架构哪个更优呢?还真的不太好说,TiDB可以像我们使用普通的集中式数据库一样来使用分布式数据库,这方面TiDB似乎更胜一筹,不过实际上并非如此。因为TiDB的完全存算分离,导致了计算节点的本地数据缓冲无法实现了,所有的数据访问都不能直接从本地缓冲里获取,而都必须通过存储节点获取。这导致了一些对延时要求较高的OLTP系统的性能无法满足,这就是所谓的“稳定的慢”。

对于一些复杂的表关联,大查询,其性能虽然说与架构相关,但是最终决定性能的还是CBO优化器的执行计划的效率,以及算子分解与并行下推的能力。因此存算分离的分布式数据库,能够以何种粒度下推算子与优化器的功力决定了最终的性能。对于存储节点是一个独立的数据库实例的分布式数据库而言,在最初的技术实现上,肯定下推的只是子SQL。下推比SQL粒度更小的算子必须在SQL引擎的核心上做工作,因此对技术要求更高。当然随着产品的发展,这种工作是必须要做的。不过目前很多采用此类架构的分布式数据库的存储引擎采用了MySQL,对于此类数据库的核心代码的修改,如果不开源,是否违反了GPL协议,我一直百思不得其解。

分布式数据库的另外一个主要流派就是对等分布式,其代表是OceanBase。此类数据库是采用分片技术的,每个分片是一个完整的rdbms实例,具有计算引擎,并带有存储引擎,用于管理本地的数据。客户端连接到任何一个分片,都可以执行SQL,不需要通过一个计算节点。这种架构的缺点是如果要把一张表打散到分布式集群中,这张表必须指定Sharding Key。不过优点是每个节点都可以通过本地缓存来提高本地数据的访问性能。

今天的讨论我主要想让读者了解,没有完美的分布式数据库架构,如果我们要来看一个分布式数据库的水平,不仅仅要看起实现架构,更重要的是要看其SQL引擎、CBO优化器和分布式执行器的能力。谁家的产品把这些做好了,就能脱颖而出。

来源:白鳝的洞穴内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯