您当前的位置:首页 > 电脑百科 > 程序开发 > 架构

程序员必备!关系型数据库架构的超强总结

时间:2019-08-16 09:14:21  来源:  作者:

来自: OceanBase技术闲谈

1. 前言

本文总结一下接触过的关系型数据库常用的几种架构及其演进历史。

分析数据库架构方案的几个视角用发生故障时的高可用性、切换后的数据一致性和扩展性。每个产品都还有自己独特的优势和功能,这里不一定会提到。

2. Oracle数据库的架构方案

ORACLE数据库既能跑OLTP业务,也能跑OLAP业务,能力是商业数据库中数一数二的。支持IBM小机和x86 PC服务器,支持多种OS。同时有多种数据库架构方案供选择,成本收益风险也各不相同。

A. IBM AIX HACMP + ORACLE9I + EMC

程序员必备!关系型数据库架构的超强总结

图 1 :IBM AIX HACMP + ORACLE9I + EMC

架构说明:

1. 两台IBM AIX A和B。AIX A运行Oracle Primary实例,AIX B分出部分资源虚拟一个OS C,运行Oracle Standby实例。AIX B剩余大部分资源空闲,用于未来起另外一个OraclePrimary实例。

2. 两台存储(EMC只是举例)A和B,分别直连两台AIX A和B。存储A存放Primary实例的日志和数据,也存放Standby实例的Redo(图中未画出,只有在角色未Primary时有效)。存储B存放Standby实例的日志和数据,也存放Primary实例的Redo文件。

3. AIX也可以换普通的x86_64 PC服务器,HACMP换为支持linux的集群软件。如Veritas HA。

功能:

1. 高可用:Oracle Primary实例不可用时,HACMP起用AIX B上的Oracle Primary实例。存储A不可用时,将AIX C上Standby实例Failover为Primary实例。

2. 数据一致性:Redo文件在两个存储上都有保留,Standby实例在Failover之前应用Primary的Redo,理论上即使是Failover也不丢数据。

3. 扩展性:数据库性能由主机aix和存储能力决定,都可以向上扩展,成本会陡升,且有上限。

B. x86 + ORACLE RAC + EMC

程序员必备!关系型数据库架构的超强总结

架构说明:

1. 两台主机A和B可以是AIX,也可以是x86_64普通PC服务器,彼此网络直连,同时连接共享的存储EMCA,A和B分别运行一个RAC Primary实例。

2. 主机C可以是AIX或x86_64普通PC服务器,直连另外一个存储B,运行Standby实例。也有的架构会有多个Standby实例,其中一个Standby实例也是RAC。

功能:

1. 高可用:Oracle RACPrimary实例无论哪个不可用,另外一个都可以自动接管服务。如果Primary实例的存储A不可用,则将Standby实例Failover为Primary实例。

2. 数据一致性:如果Primary实例也将一组Redo 成员输出到B存储,则理论上可以绝对不丢数据。否则,极端情况下,Failover可能会因为缺少Primary的事务日志而失败,此时直接激活Standby实例为Primary实例,可能会丢失少量数据。

3. 扩展性:数据库计算能力不足可以水平扩展(添加RAC节点),存储能力不足可以向上扩展(存储扩容)。

C. Oracle Dataguard 共享Redo

程序员必备!关系型数据库架构的超强总结

架构说明:

1. 普通x86服务器A和B,分别运行Oracle的Primary和Standby实例。彼此网络直连,同时连接一个共享存储。

2. Primary和Standby实例的Redo和控制文件、spfile都放在共享存储上,所以占用空间非常小。数据文件放在本机上,通常是高速存储(如SSD或者PCIE接口的Flash设备)。

功能:

1. 高可用:当Primary实例不可用时,将Standby实例Failover为Primary实例。如果共享存储不可用,则两个实例都不可用。通常会有第三个Standby实例。

2. 数据一致性:Standby实例在Failover之前应用Primary实例的Redo文件,不丢失事务日志,数据强一致。

3. 扩展性:无。

3. MySQL数据库的架构方案

A. ADHA (Alibaba Database High Availability)

程序员必备!关系型数据库架构的超强总结

架构说明:

1. 使用MySQL Master-Master架构,双向同步,Slave只读。

2. 使用Zookeeper集群做实例不可用监测和防止脑裂。

功能:

1. 高可用:Master实例不可用后,将Slave激活。可用性优先。如果Slave延时超出一定阀值,放弃切换。zk集群三节点部署,可以防止脑裂。

2. 数据一致性:为尽可能少的减少数据丢失,推荐开启单向半同步技术。同时在老Master恢复后会尽可能的弥补未及时同步到新Master的数据。由于同步依赖Binlog,理论上也是无法保证主从数据绝对一致。

3. 扩展性:可以做读写分离,可以新增slave扩展读服务能力。

B. MHA (Master High Availability)

程序员必备!关系型数据库架构的超强总结

架构说明:

1. 从MySQL主从同步架构衍生出来的,使用半同步技术,所以至少有两个从实例(Slave)。所以整体架构为一主两从,两个从库不是级联关系。

功能:

1. 高可用:Master不可用时,自动从两个Slave里选出包含Binlog最多的Slave,并提升为Master。同时更改另外一个Slave的Master为新的Master。Master异常时,Slave上的拉取的Binlog如果有丢失(master或者slave故障时),很容易出现复制中断,因此这种高可用机制并不总是有效。

2. 数据一致性:为了尽可能少的丢失Binlog,主从同步推荐使用半同步技术。在网络异常的情况下,半同步有可能降级为异步同步。MHA只是尽最大程度保证数据不丢失。且由于同步依赖的是Binlog,主从的数据理论上也并不能保证严格一致。

3. 扩展性:可以提供读写分离服务,可以新增slave节点扩展读服务能力。

C. PXC (Percona XtraDB Cluster)

程序员必备!关系型数据库架构的超强总结

架构说明:

1. 可以两个节点,推荐三个节点(防脑裂),组成一个Cluster。三节点同时提供读写服务。数据是独立的三份,不是共享存储。

2. 事务提交是同步复制,在所有从节点都同步提交。

功能:

1. 高可用:三节点同时提供读写服务,挂任意一个节点都没有影响。

2. 数据一致性:数据强同步到所有节点,不丢数据。要求有主键,某些SQL不支持同步。

3. 扩展性:事务提交是同步复制,性能受限于最差的那个节点。

4. 其他:多主复制,但不能同时写同一行数据(乐观锁,会报死锁类错误)。另外,有写放大弊端。

4. 分布式数据库中间件的架构方案

A. 分布式数据库DRDS

程序员必备!关系型数据库架构的超强总结

架构说明:

1. DRDS Server节点是一组无状态的程序,响应SQL请求并做分库分表路由转换和SQL改写、聚合计算等。支持库和表两级维度拆分,支持多种灵活的拆分策略,支持分布式事务。

2. MySQL节点主要是存储数据、主备双向同步架构,外加MySQL的PaaS平台提供高可用切换、自动化运维能力。

3. 围绕这个架构的还有数据同步组件(精卫),实现小表广播、异构索引表等能力。

4. 该架构最新版本在只读实例基础上实现了MPP并行计算引擎,支持部分OLAP查询场景。

功能:

1. 高可用:计算节点(DRDS Server节点)的高可用通过前端负载均衡设备实现,存储节点(MySQL)的高可用靠ADHA实现。RTO在40s左右,RPO>=0。

2. 数据一致性:MySQL主备同步是半同步或者异步。ADHA最大可能的降低MySQL故障切换时的主备不一致概率,理论上无法保证绝对强一致,RPO>=0。

3. 扩展性:计算和存储节点都可以分别扩容。存储的扩容通过MySQL实例的增加以及数据的迁移和重分布等。

4. 运维:故障时,主备强切后,会有一定概率出现主备同步因为数据不一致而中断。

B. 分布式数据库TDSQL

程序员必备!关系型数据库架构的超强总结

架构说明:

1. 计算节点:由一组无状态的网关节点组成,负责SQL路由、MySQL主故障时的路由切换等。

2. 调度系统:用zk集群做元数据管理、监测故障和做数据库故障切换、弹性伸缩任务等。

3. 存储节点:MySQL主备架构,一主两从,做强同步或者异步同步。

4. 支持全时态数据模型

功能:

1. 高可用:网关前端推测也有负载均衡,MySQL主备切换依赖zk判断,RTO在40s左右

2. 数据一致性:一主两备使用强同步的时候,基本可以保证RPO=0. 如果是异步,可能切换时会有延迟。

3. 扩展性:通过提升网关能力或者个数来提升计算能力,增加MySQL节点数然后调整数据分布来提升计算和存储能力。

4. 运维:异常时,可能出现主备由于数据不一致导致同步服务中断,需要修复。

C. 分布式数据库 GoldenDB

程序员必备!关系型数据库架构的超强总结

架构上也是分库分表,跟DRDS原理基本相同。

D. 分布式数据库 MyCat

程序员必备!关系型数据库架构的超强总结

架构原理和功能跟前面两类基本相同。底层存储节点还支持Oracle和Hive。

E. 分布式数据库 HotDB

程序员必备!关系型数据库架构的超强总结

5. 分布式数据库

A. google的F1

程序员必备!关系型数据库架构的超强总结
程序员必备!关系型数据库架构的超强总结

说明:

1. F1支持sql,底层可以支持MySQL和Spanner。选择Spanner原因主要是Spanner不需要手动分区、使用Paxos协议同步数据并保证强一致以及高可用。

2. Spanner分为多个Zone部署。每个zone有一个zonemaster(管理元数据和spannerserver)、多个spannerserver。

3. Spanner的数据存储在tablet里,每个tablet按固定大小切分为多个directory。Spanner以directory为单位做负载均衡和高可用,paxos group是对应到directory的。

4. Spanner的TrueTime 设计为分布式事务实现方案提供了一个新的方向(分布式MVCC)。

B. PingCap的TiDB

TiDB主要是参考Google的Spanner和F1的设计,架构上有很多相似的地方。

程序员必备!关系型数据库架构的超强总结
程序员必备!关系型数据库架构的超强总结

架构说明:

1. TiDB server负责处理SQL并做路由。无状态,可以部署多个节点,结合负载均衡设计对外提供统一的接入地址。

2. PD Server 是集群的管理模块,存储元数据和对TiKV做任务调度和负载均衡,以及分配全局唯一递增的事务ID。

3. TiKV Server 是存储节点,外部看是Key-Value存储引擎,表数据自动按固定大小(如20M,可配置)切分为多个Region分散在多台TiKV Server上。Region是数据迁移和高可用的最小单位,Region的内容有三副本,分布在三个区域,由Raft协议做数据同步和保证强一致。

4. 支持分布式事务,最早实现全局一致性快照。支持全局一致性备份。

5. 兼容MySQL主要语法。

功能:

1. 可用性:计算节点无状态部署,结合负载均衡设计保证高可用和负载均衡。存储节点是三副本部署,使用Raft协议维持三副本数据一致性和同步,有故障时自动选举(高可用)。

2. 扩展性:计算和存储分离,可以单独扩展。存储节点扩展后,数据会重新分布,应该是后台异步任务完成,不影响业务读写,可以在线扩容。可以用于做异地容灾,两地三中心异地多活(三机房之间网络延时很小)

3. 数据一致性:计算节点故障不会导致数据丢失,存储节点故障会自动选举,新的leader跟老的leader数据是强一致的。

C. Alipay的OceanBase

OceanBase的设计思路跟Spanner类似,但在SQL、存储、事务方面都有自己的创新。

程序员必备!关系型数据库架构的超强总结

架构说明:

1. 目前版本计算和存储都集中在一个节点上(PC,OBServer)上,单进程程序,进程包括SQL引擎和存储引擎功能。

2. 表数据存在一个或多个分区(使用分区表),需要业务指定分区规则。分区是数据迁移和高可用的最小单位。分区之间的一致性是通过MultiPaxos保证。

3. 支持分布式事务、2.x版本支持全局一致性快照。支持全局一致性备份。

4. 兼容MySQL主要用法和Oracle标准SQL用法,目前正在逐步兼容Oracle更多功能。如存储过程、游标和Package等。目标是兼容Oracle常用功能以实现去IOE时应用不修改代码的目标。

5. 有多租户管理能力,租户弹性扩容,租户之间有一定资源隔离机制。

6. 应用可以通过一个反向代理obproxy或者ob提供的connector-JAVA访问OceanBase集群。

跟Spanner的关系和区别:

1. Spanner大概2008年开始研发,2012年通过论文对外公开。首次跨地域实现水平扩展,并基于普通PC服务器实现自动高可用和数据强一致。OceanBase在2010年开始立项研发,也是基于普通PC服务器,发展出自己独特的ACID特性和高可用技术以及拆分技术。

2. Spanner对标准SQL支持不好,不是真正的关系型数据库,定位于内部应用。OceanBase定位于通用的分布式关系型数据库,支持标准SQL和关系模型。基本兼容MySQL功能,逐步兼容Oracle功能。

3. Spanner借助原子钟硬件和TrueTime设计支持全局一致性快照,提供快照读隔离级别,对节点间网络延时要求比较高。OceanBase使用软件提供全局时间服务,实现了全局一致性快照功能。

4. Spanner的内部诊断跟踪机制很欠缺,OceanBase的内部诊断分析机制功能很完善,是瞄准商业软件标准去做的。

功能:

1. 扩展性:租户和集群的弹性伸缩非常方便,可以在线进行,对业务写影响可控。可以用于两地三中心异地容灾和多活(结合业务做单元化设计)。

2. 可用性:单个或多个observer不可用时,只要分区的绝大部分成员存活,则可以迅速选举恢复服务(RTO=20s)。

3. 数据一致性:故障恢复后,数据库数据绝对不丢。RPO=0。



Tags:数据库架构   点击:()  评论:()
声明:本站部分内容及图片来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,如有任何标注错误或版权侵犯请与我们联系(Email:2595517585@qq.com),我们将及时更正、删除,谢谢。
▌相关推荐
为正确的案例选择正确的模式 前言困惑的特德恳求说:"很难相信这是不可能的。""这是2020年;当然,必须有另一种方式"。这是Acme Widgets的教学时刻。他们技术堆栈中的数据库发生...【详细内容】
2020-12-07  Tags: 数据库架构  点击:(156)  评论:(0)  加入收藏
一、SMP数据库架构SMP(对称多处理器结构,Symmetric Multi-Processor)数据库架构部署成本相对较低,可以运行从大型服务器到中型商用硬件的各种设备。它在提供合理的性能和吞吐量...【详细内容】
2020-12-01  Tags: 数据库架构  点击:(535)  评论:(0)  加入收藏
在分布式系统里面,往往制约整个系统发展的瓶颈点就是数据库,所以数据库的架构和高可用以及数据库的切分都是我们值得花大力气去学习的。首先我们来说说数据库的架构。1、mysql...【详细内容】
2020-06-09  Tags: 数据库架构  点击:(55)  评论:(0)  加入收藏
本文以MYSQL数据库为例说明。一、数据库架构原则有以下几种:1、高可用2、高性能3、一致性4、扩展性二、常见的架构方案: 方案一:主备架构,只有主库提供读写服务,备库冗余作故障转...【详细内容】
2019-12-24  Tags: 数据库架构  点击:(119)  评论:(0)  加入收藏
数据库作为基础软件中的重要一环有着很深的技术含量,在这样的大背景下国产数据库厂商开始发力,这其中分布式数据库如雨后春笋般出现,良性的竞争环境使它们都得到了长足的发展,其...【详细内容】
2019-11-19  Tags: 数据库架构  点击:(152)  评论:(0)  加入收藏
背景在互联网初创时期,企业往往采用单体架构去搭建自己的应用系统,但是,随着企业的不断壮大,系统访问量不断随之上升,数据量也急剧增长。数据的存储是首先要解决的问题,在这个大数...【详细内容】
2019-11-01  Tags: 数据库架构  点击:(120)  评论:(0)  加入收藏
一、数据库架构原则 高可用 高性能 一致性 扩展性二、常见的架构方案方案一:主备架构,只有主库提供读写服务,备库冗余作故障转移用 jdbc:mysql://vip:3306/xxdb1、高可用分析:高...【详细内容】
2019-09-27  Tags: 数据库架构  点击:(121)  评论:(0)  加入收藏
一、数据库架构原则 高可用 高性能 一致性 扩展性二、常见的数据库架构方案方案一:主备架构,只有主库提供读写服务,备库冗余作故障转移用 jdbc:mysql://vip:3306/xxdb1、 高...【详细内容】
2019-09-16  Tags: 数据库架构  点击:(195)  评论:(0)  加入收藏
本文总结一下接触过的关系型数据库常用的几种架构及其演进历史。...【详细内容】
2019-08-16  Tags: 数据库架构  点击:(254)  评论:(0)  加入收藏
一、数据库架构原则 高可用 高性能 一致性 扩展性二、常见的架构方案方案一:主备架构,只有主库提供读写服务,备库冗余作故障转移用 jdbc:mysql://vip:3306/xxdb1、高可用分析...【详细内容】
2019-06-28  Tags: 数据库架构  点击:(347)  评论:(0)  加入收藏
▌简易百科推荐
为了构建高并发、高可用的系统架构,压测、容量预估必不可少,在发现系统瓶颈后,需要有针对性地扩容、优化。结合楼主的经验和知识,本文做一个简单的总结,欢迎探讨。1、QPS保障目标...【详细内容】
2021-12-27  大数据架构师    Tags:架构   点击:(5)  评论:(0)  加入收藏
前言 单片机开发中,我们往往首先接触裸机系统,然后到RTOS,那么它们的软件架构是什么?这是我们开发人员必须认真考虑的问题。在实际项目中,首先选择软件架构是非常重要的,接下来我...【详细内容】
2021-12-23  正点原子原子哥    Tags:架构   点击:(7)  评论:(0)  加入收藏
现有数据架构难以支撑现代化应用的实现。 随着云计算产业的快速崛起,带动着各行各业开始自己的基于云的业务创新和信息架构现代化,云计算的可靠性、灵活性、按需计费的高性价...【详细内容】
2021-12-22    CSDN  Tags:数据架构   点击:(10)  评论:(0)  加入收藏
▶ 企业级项目结构封装释义 如果你刚毕业,作为Java新手程序员进入一家企业,拿到代码之后,你有什么感觉呢?如果你没有听过多模块、分布式这类的概念,那么多半会傻眼。为什么一个项...【详细内容】
2021-12-20  蜗牛学苑    Tags:微服务   点击:(9)  评论:(0)  加入收藏
我是一名程序员关注我们吧,我们会多多分享技术和资源。进来的朋友,可以多了解下青锋的产品,已开源多个产品的架构版本。Thymeleaf版(开源)1、采用技术: springboot、layui、Thymel...【详细内容】
2021-12-14  青锋爱编程    Tags:后台架构   点击:(21)  评论:(0)  加入收藏
在了解连接池之前,我们需要对长、短链接建立初步认识。我们都知道,网络通信大部分都是基于TCP/IP协议,数据传输之前,双方通过“三次握手”建立连接,当数据传输完成之后,又通过“四次挥手”释放连接,以下是“三次握手”与“四...【详细内容】
2021-12-14  架构即人生    Tags:连接池   点击:(17)  评论:(0)  加入收藏
随着移动互联网技术的快速发展,在新业务、新领域、新场景的驱动下,基于传统大型机的服务部署方式,不仅难以适应快速增长的业务需求,而且持续耗费高昂的成本,从而使得各大生产厂商...【详细内容】
2021-12-08  架构驿站    Tags:分布式系统   点击:(23)  评论:(0)  加入收藏
本系列为 Netty 学习笔记,本篇介绍总结Java NIO 网络编程。Netty 作为一个异步的、事件驱动的网络应用程序框架,也是基于NIO的客户、服务器端的编程框架。其对 Java NIO 底层...【详细内容】
2021-12-07  大数据架构师    Tags:Netty   点击:(17)  评论:(0)  加入收藏
前面谈过很多关于数字化转型,云原生,微服务方面的文章。虽然自己一直做大集团的SOA集成平台咨询规划和建设项目,但是当前传统企业数字化转型,国产化和自主可控,云原生,微服务是不...【详细内容】
2021-12-06  人月聊IT    Tags:架构   点击:(23)  评论:(0)  加入收藏
微服务看似是完美的解决方案。从理论上来说,微服务提高了开发速度,而且还可以单独扩展应用的某个部分。但实际上,微服务带有一定的隐形成本。我认为,没有亲自动手构建微服务的经历,就无法真正了解其复杂性。...【详细内容】
2021-11-26  GreekDataGuy  CSDN  Tags:单体应用   点击:(35)  评论:(0)  加入收藏
最新更新
栏目热门
栏目头条