Distributed Database System —— 分布式数据库的两种架构风格

文章目录

  • 概述
  • PGXC:单体数据库的自然演进
  • NewSQL:革命性的新架构

概述

总的来说,分布式数据库大多可以分为两种架构风格

  • 一种是 NewSQL,它的代表系统是 Google Spanner;
  • 另一种是从单体数据库中间件基础上演进出来的,被称为 Prxoy 风 格,没有公认的代表系统,便于理解,所以选了一个出现较早的产品来指代这种风 格,这就是 PostgreSQL-XC(下文简称 PGXC)。

数据库从逻辑上拆分为 5 个部分,分别是客户端通讯管理器 (Client Communications Manager)、查询处理器(Relational Query Processor)、事务存储管理器(Transactional Storage Manager)、进程管理器 (Process Manager)和共享组件与工具 (Shared Components and Utilities),每个部分下面又可以拆分成一些组件。

  • 客户端通讯管理器。这是应用开发者能够直观感受到的模块,通常我们使用 JDBC 或者 ODBC 协议访问数据库时,连接的就是这个部分。
  • 进程管理器。连接建好了,数据库会为客户端分配一个进程,客户端后续发送的所有操 作都会通过对应的进程来执行。
  • 查询处理器。它包括四个部分,功能上是顺序执行的。首先是解析器,它将接收到的 SQL 解析为内部的语法树。然后是查询重写(Query Rewrite),它也被称为逻辑优化,主要是依据关系代数的等价变换,达到简化和标准化的目的,比如会消除重复条件或去掉一些无意义谓词 ,还有将视图替换为表等操作。再往后就是查询算法优化 (Query Optimizer),它也被称为物理优化,主要是根据表连接方式、连接顺序和排 序等技术进行优化,我们常说的基于规则优化(RBO)和基于代价优化(CBO)就在这部分。最后就是计划执行器(Plan Executor),最终执行查询计划,访问存储系统。
  • 事务存储管理器。它包括四个部分,其中访问方式(Access Methods)是指数据在磁盘的具体存储形式。锁管理(Lock Manager)是指并发控制。日志管理(Log Manager)是确保数据的持久性。缓存管理(Buffer Manager)则是指 I/O 操作相关 的缓存控制。
  • 共享组件和工具。在整个过程中还会涉及到的一些辅助操作,当然它们对于数据库的运行也是非常重要的。例如编目数据管理器(Catalog Manager)会记录数据库的表、字 段、视图等元数据信息,并根据这些信息来操作具体数据内容。复制机制 (Replication)也很重要,它是实现系统高可靠性的基础,在单体数据库中,通过主备节点复制的方式来实现数据的复制。

PGXC:单体数据库的自然演进

单体数据库的功能看似已经很完善了,但在面临高并发场景的时候,还是会碰到写入性能不足的问题,很难解决。因此,也就有了向分布式数据库演进的动力。要解决写入性能不足的问题,大家首先想到的,最简单直接的办法就是分库分表

分库分表方案就是在多个单体数据库之前增加代理节点,本质上是增加了 SQL 路由功能。 这样,代理节点首先解析客户端请求,再根据数据的分布情况将请求转发到对应的单体数据库

一般是两种分片方式: By Range或者By HashValue

有了分库分表,跨库事务成为必不可少的功能,但是单体数据库是不感知这个事情的,所以我们就要在代理节点增加分布式事务组件

比如说使用2PC等等。

同时,简单的分库分表不能满足全局性的查询需求,因为每个数据节点只能看到一部分数 据,有些查询运算是无法处理的,比如排序、多表关联等。所以,代理节点要增强查询计算能力,支持跨多个单体数据库的查询。

随着分布式事务和跨节点查询等功能的加入,代理节点已经不再只是简单的路由功能,更 多时候会被称为协调节点。

这时离分布式数据库还差重要的一 步,就是全局时钟。加上这最后一块拼图,PGXC 区别于单体数据库的功能也就介绍完整了,它们是分片、分布式事务、跨节点查询和全局时钟

NewSQL:革命性的新架构

NewSQL也叫原生分布式数据库,我觉得这个名字能更准确地体现这类架构风格的特点,就是说它的每个组件在设计之初都是基于分布式架构的,不像 PGXC 那样带有明显的单体架构痕迹

NewSQL 的基础是 NoSQL,更具体地说,是类似 BigTable 的分布式键值(K/V)系统。 分布式键值系统选择做了一个减法,完全放弃了数据库事务处理能力,然后将重点放在对 存储和写入能力的扩展上,这个能力扩展的基础就是分片。引入分片的另一个好处是,系 统能够以更小的粒度调度数据,实现各节点上的存储平衡和访问负载平衡。

分布式键值系统由于具备这些鲜明的特点,所以在不少细分场景获得了成功(比如电商网 站对于商品信息的存储),但在面对大量的事务处理场景时就无能为力了(比如支付系统)。这种状况直到 Google Spanner 横空出世才被改变,因为 Spanner 基于 BigTable 构建了新的事务能力

NewSQL 还有两个重要的革新,分别出现在高可靠机制存储引擎的设计上。

  • 高可靠机制的变化在于,放弃了粒度更大的主从复制,转而以分片为单位采用 Paxos 或 Raft 等共识算法。这样,NewSQL 就实现了更小粒度的高可靠单元,获得了更高的系统整 体可靠性。
  • 存储引擎层面,则是使用 LSM-Tree 模型替换 B+ Tree 模型,大幅提升了写入 性能。

NewSQL 的架构设计也不是完美无缺。比如,作为一个计算与存储分离得更加彻底 的架构,NewSQL 的计算节点需要借助网络才能与存储节点通讯,这意味着要花费更大的代价来传输数据。随着 NewSQL 分布式数据库的应用实践越来越多,很多产品为了获得更好的计算性能,会尽量将更多计算下压到存储节点执行。这种架构上的修正,似乎也可以 理解为,NewSQL 朝 PGXC 的方向做了一点回拨。

NewSQL 的 Range 分片,多数是用主键作为关键字来分片的。

  • 分片可以自动完成分裂与合并
    当单个分片的数据量超过设定值时,分片可以一分为二,这样就可以保证每个分片的数据 量较为均衡。多个数据量较少的分片,会在一定的周期内被合并为一个分片。
  • 可以根据访问压力调度分片
    我们看到系统之所以尽量维持分片之间,以及节点间的数据量均衡,存储的原因外,还可以更大概率地将访问压力分散到各个节点上。

参考:分布式数据库

你可能感兴趣的:(分布式架构)