数据库作为基础软件中的重要一环有着很深的技术含量,在这样的大背景下国产数据库厂商开始发力,这其中分布式数据库如雨后春笋般出现,良性的竞争环境使它们都得到了长足的发展,其中不乏优秀的产品,本文主要挑选目前几个相对成熟数据库进行架构特点介绍。

作者:张小海来源:51CTO

【51CTO.com原创稿件】

行业背景

随着全球经济下行压力增大,中美贸易摩擦愈演愈烈,美国一系列的经济制裁和技术封锁使得我们有种被扼住咽喉的感觉,数据库作为基础软件中的重要一环有着很深的技术含量,在这样的大背景下国产数据库厂商开始发力,这其中分布式数据库如雨后春笋般出现,良性的竞争环境使它们都得到了长足的发展,其中不乏优秀的产品,本文主要挑选目前几个相对成熟数据库进行架构特点介绍。

分布式数据库总体架构

分布式数据库总体设计有两个思路和方向,一个是基于共享存储的架构(share everything),另一个是基于数据分片的架构(share nothing)。

共享存储的架构特点是底层存储共用一份数据池子,上层数据库server层可以弹性扩展,典型的案例像DB2 pureScale,Oracle RAC,阿里云PolarDB等,这种架构的好处是天然适合做云数据库,比如阿里云,上层的SQL引擎可以是MySQL也可以是PG,而且可以无限扩展,底层的存储其实是一起的,用户申请只是申请几个上层的MySQL或者PG server同时在底层存储开辟一块空间给用户,这样的话可以做到资源的弹性伸缩。这种架构的数据库严格意义上不能称之为分布式数据库。

数据分片架构的特点是底层数据通过一定的规则比如hash或者range让数据打散分别分布到不同的数据节点上,计算时底层多个节点共同参与计算,可以算是一种mpp并行计算的架构,同时数据节点可以扩展,上层由协调节点进行SQL解析和转发,这是目前典型的分布式数据库架构,也是本文讨论的重点。

目前分布式数据库的总体架构设计基本都和下图相差不大,每种产品在不同组件的实现上存在差异,但大体架构上类似。

从图中可以看到分布式数据库三大组件:协调节点、数据节点、全局事务管理器。协调节点负责SQL解析转发,充当的是类似proxy的角色,数据节点负责计算和数据存储,全局事务管理器负责全局事务读一致性的保证。

下面分别介绍一下目前主流的分布式数据库的架构以及设计差异。

1.TiDB

TiDB是目前在互联网界风靡的一款分布式数据库,由PingCAP公司研发,由三大组件构成,底层TiKV Server是Github开源组件,是一个分布式的kv存储引擎,做数据存储,对应数据节点;上层TiDB Server由PingCAP公司研发,用作SQL解析和转发,对应协调节点;PD Server复制全局时间戳分配,对应全局事务管理器。下面列举了它的架构特点:

①轻量化,深受互联网公司喜爱,适合与容器进行集成,当前PingCAP公司也在做TiDB operator,将TiDB容器化。

②部署简便,基于Ansible Playbook实现自动化部署。

③实现了基于Region级别的raft复制,将数据表拆分成一个个的Region,Region一主两备基于raft协议做复制,同时Region还会根据负载情况进行合并和分裂,由PD Server进行负载均衡调度。

④使用隐藏列作为分布列,分布列不占用真实列,这样在进行数据修改时数据不需要进行重分布,大致原理是使用表名和主键前面加上前缀信息作为隐藏列,再使用该列进行hash分布。

⑤TiDB Server总体兼容MySQL语法,这个兼容并不是将MySQL Server直接拿过来使用,因为TiKV底层是kv的存储模型,所以TiDB在执行sql的时候需要做sql到kv的映射。

⑥TiKV可以看成一个大的数据池子,在物理机层面不存在哪个机器是主,哪个是备,所有机器都是主节点,热点数据会自动进行动态负载均衡,数据是动态移动的。

⑦总体借鉴了google spanner f1和bigtable的论文,PD Server实现了逻辑上的时间戳,谷歌论文也提出了原子钟的概念,从物理上保证事务号全局有序。

2.OceanBase

OceanBase是蚂蚁金服自研的分布式数据库,号称代码从第一行完全自研。最近ob也屡屡刷新新闻头条,刷榜TPCC官网测试结果,刷新天猫交易额和tps记录,不过金融行业比如银行的应用案例并不多,也许是银行和支付宝可能天然有鸿沟吧。ob架构比较特殊,下面介绍一下它的架构特点:

①最底层是ob server,每个ob server集成了总控服务、sql引擎、存储引擎和数据分区。

②上层是ob proxy,实现sql的路由,这个不止是应用到observer的路由,也有observer之间的路由。

③数据拆成一个个分区,每个分区做paxos复制,保证强一致,主分区宕机不可用会自动切换到备分区。

④checkpoint时间改变,将checkpoint周期拉长为1天,所有交易都落在内存,然后每天夜里去刷一次盘,redo日志实时记录,这样避免了随机写的性能损耗,只有顺序写,更像内存数据库,性能更好,这样也带来一些问题,比如宕机后恢复时间变长,还有查询刚刚做的修改需要先查基础数据,再去应用redo条目,得到最新数据。

⑤两阶段提交并不使用ob proxy节点充当协调者,而是将ob proxy路由到的第一个主数据分区作为协调者,同时两阶段提交的prepare和commit等信息会进行持久化,如果写协调节点宕机,那么备分区会启用,同时读取持久化信息,这个设计和一般的分布式数据库不太一样。

⑥集群维护一个partition cache,分区的分布信息会通过ob proxy在不同ob server间传递。

⑦ob最早的时候曾经开源过一段时间,随后基于它也诞生了cbase、obase这些产品。

3.GaussDB

华为GaussDB分为三个产品线,Gauss100前身是华为自研的内存数据库gmdb,目前已经开源,Gauss200是基于pgxc架构研发的OLAP分析型数据库,Gauss300是在200的基础上继续研发的HTAP数据库,这里主要介绍Gauss300数据库,Gauss300就是上图中典型的架构:

①协调节点负责sql解析、转发的同时也充当了两阶段提交的协调者的角色,协调节点上面存储有部分元数据信息,元数据需要在多个协调节点之间进行同步,如果协调节点宕机,会影响ddl相关操作,还可能造成两阶段提交的残留信息,需要有两阶段残留清理机制。

②数据节点通过quorum-based流复制实现高可用,主备数据节点是实例级别的,一个主节点就是一个主PG实例,一台机器可以有多个主数据节点。

③GTM复制分配全局事务id,GTM一主多备,GTM主备之间要同步gxid信息,而且是强同步,那么带来一个问题,备GTM节点宕机会造成主GTM不可用,造成全局可用性问题,这块华为将GTM的高可用转移到etcd中,将GTM生成的xid写入到etcd中,etcd自身就是一个高可用强一致的集群,这样就保证了GTM的高可用,主GTM宕机那么备GTM会接替,然后继续从etcd集群中读写事务号。

④GTM的事务号是批量分配的,如果在高并发的情况下,gxid如果一条一条分配则会有性能瓶颈,华为将事务号改为一次分配几万甚至几十万,避免了GTM事务号分配的瓶颈。

⑤事务id由32位改为64位。PG的事务号是32位的,最大到42亿,所以事务号在PG中是很珍贵的资源,用完了就会循环使用,循环使用会带来很多严重问题,华为将事务号由32位改为了64位,这样事务号根本不可能用尽,那么一次分配几十万也不足为奇了。

⑥为了提升性能,华为也正在研发gtm-lite功能,该功能可以实现本地事务不走GTM,因为生产环境大部分是本地事务,因而能大大提升性能。

⑦Gauss300是基于pgxc架构演进而来的,类似基于pgxc的还有亚信AntDB、腾讯TBase。

4.SequoiaDB

SequoiaDB是巨杉自主研发的分布式数据库,最初的应用场景主要是历史数据归档和非结构化数据存档,但是近期来巨杉也在积极开发oltp功能,包括研发GTM,支持MySQL协议等。下面介绍一下它的架构特点:

①包括协调节点、编目节点、数据节点、PG节点等。协调节点负责sql转发,编目节点存储元数据,数据节点存储真实数据,PG节点做sql引擎。

②巨杉数据库底层存储是NoSQL的,数据都是JSON格式进行存储,优点类似MongoDB。

③PG节点是将PG Server拿过来做sql存储引擎,支持sql语法,在PG上创建外表,同时创建外部服务器,存取巨杉中的数据,近期也支持了MySQL,将巨杉作为可插拔的存储引擎嵌入到MySQL中。

④目前巨杉用作交易类场景其实不多,现在最大的一个应用案例是某大行一百多物理节点的巨杉集群,用作数据归档和影像管理。

⑤巨杉底层是多模存储引擎,既支持结构化数据,也支持非结构化数据,实现了统一管理。

当然还有很多分布式数据库,像达梦、人大金仓、南大通用、万里开源、中兴等企业都有分布式数据库产品,这里不再一一介绍了。

作者介绍:

张小海,就职于某大型商业银行,目前主要负责数据库管理及新技术研究,PostgreSQL技术推广者,个人公众号:数据库架构之美。

1.《分布式架构 全面讲解分布式数据库架构设计特点》援引自互联网,旨在传递更多网络信息知识,仅代表作者本人观点,与本网站无关,侵删请联系页脚下方联系方式。

2.《分布式架构 全面讲解分布式数据库架构设计特点》仅供读者参考,本网站未对该内容进行证实,对其原创性、真实性、完整性、及时性不作任何保证。

3.文章转载时请保留本站内容来源地址,https://www.lu-xu.com/keji/346823.html