精华内容
下载资源
问答
  • 2022-03-19 00:14:14

    从数据库架构设计的角度,主要有三种,Shared Everything、Shared Disk以及Shared Nothing。

    1. Shared Everything

    一般指的是单个主机的环境,完全透明共享的CPU/内存/硬盘,并行处理能力是最差的,典型代表就是SQL Server、单机版Oracle和MySQL,一般不考虑大规模的并发需求,架构比较简单,一般的应用需求基本都能满足。

    2. Shared Disk

    各处理单元使用自己的私有CPU和Memory,共享磁盘系统。典型的代表是Oracle RAC、DB2 PureScale。例如Oracle RAC,他用的是共享存储,做到了数据共享,可通过增加节点来提高并行处理的能力,扩展能力较好,使用Storage Area Network (SAN),光纤通道连接到多个服务器的磁盘阵列,降低网络消耗,提高数据读取的效率,常用于并发量较高的OLTP应用。其类似于SMP(对称多处理)模式,但是当存储器接口达到饱和的时候,增加节点并不能获得更高的性能,同时更多的节点,则增加了运维的成本。

    991ba66f0fdd68ba7e57d1bdb3664d32.png

    3. Shared Nothing

    各处理单元都有自己私有的CPU/内存/硬盘等,Nothing,顾名思义,不存在共享资源,类似于MPP(大规模并行处理)模式,各处理单元之间通过协议通信,并行处理和扩展能力更好。典型代表DB2 DPF、带分库分表的MySQL Cluster,各节点相互独立,各自处理自己的数据,处理后的结果可能向上层汇总或在节点间流转。

    如果更准确地说,Shared Nothing架构又分为两种,一种是分布式架构,将数据库中的数据按照某一标准分布到多台机器中,查询或插入时按照条件查询或插入对应的分区。另外一种是每一个节点完全独立,节点之间通过网络连接,通常是通过光纤等专用网络。

    我们常说的Sharding其实就是Shared Nothing,他是将某个表从物理存储上被水平分割,并分配给多台服务器(或多个实例),每台服务器可以独立工作,具备共同的schema,例如MySQL Proxy和Google的各种架构,只需增加服务器数就可以增加处理能力和容量。

    随着云计算、虚拟化的发展,这种架构的使用场景越来越多,例如双十一购物、春运抢票、微博热搜等,在Shared Nothing架构下,可以快速实现资源的扩容和收缩,这是Shared Everything和Shared Disk架构不具备的优势。

    但是凡事都得两面看,带来资源灵活性的同时,他对应用设计开发人员有可能提出了更高的要求,例如有些需要进行分区的,应用得配合改造,跨机访问上,可能比单机,要考虑的更多。

    上面提到的MPP,指的是大规模并行分析数据库(Analytical Massively Parallel Processing (MPP) Databases),他是针对分析工作负载进行了优化的数据库,一般需要聚合和处理大型数据集。MPP数据库往往是列式的,因此MPP数据库通常将每一列存储为一个对象,而不是将表中的每一行存储为一个对象。这种体系结构使复杂的分析查询可以更快,更有效地处理。例如TeraData、Greenplum,GaussDB100、TBase。

    近期更新的文章:

    关于数据治理的读书笔记 - 数据治理路线图规划

    Oracle优化器对谓词顺序处理的一个场景

    究竟哪些语句是属于DDL?

    最近碰到的问题

    关于数据治理的读书笔记 - 数据治理能力成熟度评估

    文章分类和索引:

    公众号900篇文章分类和索引

    更多相关内容
  • 分布式数据库架构及企业实践——基于Mycat中间件由资深 Mycat 专家及一线架构师、DBA 编写而成。全书总计 8 章,首先简单介绍了分布式系统和分布式数据库的需求,然后讲解了分布式数据库的实现原理,并对市场上存在...
  • 分布式数据库架构及企业实践-基于Mycat中间件【高清版本】这是个压缩包,里面是个pdf文件,详细的介绍了mycat中间件的使用方法。 内容简介 本书由资深 Mycat 专家及一线架构师、DBA 编写而成。全书总计 8 章,首先...
  • 分布式数据库 Mycat . 分布式数据库架构及企业实践 基于Mycat中间件.pdf
  • 数据库架构设计一次搞定,通俗易懂的数据库设计讲解。 • [ex] 百度 - 高级工程师 • [ex] 58同城 - 高级架构师,技术委员会主席,技术学院优秀讲师 • [now] 到家集团 - 技术中心负责人,技术委员会主席 • [now] ...
  • 分布式数据库架构及企业实践-基于Mycat中间件.pdf 2017-07-01 上传大小:62.13MB 分布式数据库
  • 诉求 •100亿的数据量 •10万的幵发 •1万属性 •任意字段都可能进行组合查询
  • 分布式数据库架构及企业实践:基于Mycat中间件 分布式数据库架构及企业实践:基于Mycat中间件
  • mycat数据库分布式中间件.分布式数据库架构及企业实践分布式数据库架构及企业实践
  • 书名: 分布式数据库架构及企业实践——基于Mycat中间件 作者:周继锋 冯钻优 陈胜尊 左越宗 ISBN:978-7-121-30287-9 出版年月:2016年11月 定价:79元 开本:787×980 1/16 普通关键词:计算机 分布式 数据库 学科...
  • 很多公司都在开发自己的分布式数据库架构,且不少公司都可能使用上了,也有很多人在讲分布式数据库架构,这些是真正意义上的分布式数据库吗?若要我加一个词的话,我一般说伪分布式或者说所谓的分布式数据库架构,是跟...
  • 快狗打车(原58速运)是一个创业型公司,技术架构、技术体系、数据库架构的变迁,和在座很多公司是很相近的,今天和大家聊一聊,我们在快狗打车数据库架构一致性方面碰到一些问题。主线是我们的数据库架构变化的过程,...
  • 基于MyCat实现的分布式使句酷架构及企业实践。主要讲述了利用MyCat实现数据库的分布式架构,MyCat是有中国人自主研发的数据库中间件,也是为数不多的有中国人自主研发的软件之一。
  • 饿了么数据库架构演进

    热门讨论 2016-04-08 09:23:17
    饿了么数据库架构演进_虢国飞_饿了么DBA经理
  • 分布式数据库架构及企业实践-基于Mycat中间件分布式数据库架构及企业实践-基于Mycat中间件分布式数据库架构及企业实践-基于Mycat中间件分布式数据库架构及企业实践-基于Mycat中间件分布式数据库架构及企业实践-基于...
  • mysql数据库架构视频教程 mysql数据库架构视频教程 mysql数据库架构视频教程
  • 互联网公司技术架构资料.淘宝.数据库架构演进历程,从无到有,从浅到深
  • 分布式数据库架构及企业实践-基于Mycat中间件 高清pdf
  • 阿里巴巴研究员MySQL数据库架构的演化观察的PPT,主要内容是Mysql架构演进的动力、架构演进的路径和技术社区的变化
  • 做为目前主流的模型数据库类型,关系型数据库的架构随着业务规模的增长做出相应的变化,本章我们来学习关系型数据库架构的变化以及主流的应用场景。 关系型数据库架构 随着业务规模增大,数据库存储的数据量和承载的...
  • 数据库设计 高并发 表、索引、分区设计与分析及解决方案 内存数据库timesten
  • 目录分布式数据库架构分布式数据库发展梗概关于数据库文件系统了解一下LSM-TreeB+Tree VS LSM-Tree第一代分布式数据库——分库分表及分布式中间件普通分布式中间件阿里OceanBase数据库第二代分布式数据库——NoSQL第...

    分布式数据库架构

    这个系列文章是笔者自己学习分布式数据库的记录,共有两篇,分别是:
    (一)分布式数据库架构
    (二)分布式数据库事务

    本篇是该系列的第一篇,将从分布式的概念出发,阐述笔者理解的分布式数据库三个发展阶段,并分别介绍每个阶段的代表性的数据库及其架构,这些数据库也会在后面对分布式事务的介绍中作为样例分析。

    笔者水平有限,如有错误恳请指正。文中的部分图片获取自网络,侵删。

    分布式数据库发展梗概

    分布式是面向业务扩展而出现的一个概念,而分布式数据库,就是为了解决存储可扩展性的一类数据库。笔者认为除了最初的分库分表方案,分布式数据库经历了三个主要发展阶段。第一代是分布式中间件的形式,大多数是基于MySQL数据库做Data Sharding和水平扩展;第二代是以Cassandra、MongoDB为代表的NoSQL;第三代是以AWS Aurora和Google Spanner为代表的云数据库,或者称作NewSQL。

    这三个阶段在分布式这个概念上没有本质上的区别,但是在具体的实现上有不同的侧重点,比如NoSQL就不支持跨分片的ACID事务。大家要注意并不是越新的概念的就越先进,实际上,现在市面上主流的分布式数据库,大多是分布式中间件的形式。

    关于数据库文件系统

    在具体介绍各类分布式数据库之前,我们先来了解一下在数据库中实际存储数据的数据库文件系统。
    目前主流的数据库文件系统有两类,一类是关系型数据库(如MySQL)使用的B+Tree,另一类是多用于键值存储数据库(如NoSQL)的LSM-Tree数据结构。分布式数据库建立在分布式文件系统之上,在底层实现上也是依赖于这两类数据结构的。

    了解一下LSM-Tree

    相信大家对B+Tree都有一定程度的了解,但对LSM-Tree可能就没那么熟悉了,这里我们简单介绍一下LSM-Tree。
    LSM-Tree,全称Log Structured Merge Tree,是一种写入操作不做原地更新,而是以追加的方式写入内存,每次写到一定程度,即冻结为一层,然后写入持久化存储的数据结构。
    我们可以简单描述一下一条数据在LSM-Tree中的写入过程:写入Log -> 写入memtable -> flush入持久化存储 -> 经compaction操作进入持久化存储的更新层 -> 同一key的新数据到来时丢弃。
    下面是一张LSM-Tree的结构图。
    LSM-Tree架构

    B+Tree VS LSM-Tree

    我们来比较一下这两类数据结构,明确它们的特性和适用场景。
    B+Tree将数据拆分为固定大小的Block或Page,Page是读写的最小单位。B+Tree可以做到原地更新和删除,因此对数据库事务的支持更加友好,因为一个key只会出现一个Page页里面。
    而LSM-Tree的设计思路是将数据拆分为几百M大小的Segment,并顺序写入。LSM-Tree只能追加写,并且在L0层key的range会重叠,所以对事务支持较弱,只能在Segment Compaction的时候真正地更新和删除。

    B+Tree的优点是支持高效的读(稳定的O(logN)的复杂度),但对大规模的写请求的效率就比较低(O(logN)复杂度),这是因为在大规模写的情况下,为了维护B+Tree的结构,B+Tree的节点就会不断分裂,操作磁盘的随机读写概率会变大,从而导致写性能降低。
    LSM-Tree则相反,支持高吞吐量的写(O(1)),但普通LSM-Tree读取的复杂度是O(n),在使用索引或者缓存优化后可以达到O(logN)。

    我们可以粗略的认为未优化的LSM-Tree的写比B+Tree快一个数量级,未优化的LSM-Tree的读比B+Tree慢一个数量级。

    第一代分布式数据库——分库分表及分布式中间件

    最初面对存储扩展问题,一个比较直接的思路就是分库分表——一个库装不下,我就用多个库装。

    假设一开始我们有一个单点的MySQL数据库,随着业务增长,达到了单库的存储性能瓶颈,准备使用三到五个MySQL来重新安排存储。在最理想的情况下,我们可以在拥有原来三到五倍存储空间的情况下,也能有三到五倍的并发来提升存储性能。

    但这有两个很明显的问题:第一个是我要对业务进行大量的改造,找到一个合适的维度打散业务进入多个库(而且这种完美的方案还不一定存在),而且跨库的业务也要重新写业务逻辑。第二个是一旦库又满了,我想再做一次扩容的工作,我就又要把这部分的工作再做一次——包括重写业务。

    上面两个问题的代价显然是不可承受的,这时候就有分布式数据库厂家来说了:我们来做整合并管理多个库的工作,你们应用只要把多个数据库当作原来的一个库使用即可。

    这就诞生了分布式中间件的概念,或者称作分布式关系型数据库。分布式中间件,是从关系型数据库出发,加入分布式技术,实现分布式的高可用性和高扩展性等特性。本文把此类数据库称为分布式中间件,不代表它们就没有对底层数据库(通常是MySQL)做任何改动。实际上,目前市面上的分布式关系型数据库几乎都对底层数据库有自己的修改,甚至有阿里的OceanBase那样自己实现一个关系型底层的情况。

    但是,分布式中间件 有根本解决上面的两个问题吗?显然并没有。分布式中间件没有把数据自动分片的能力,应用也不能真真正正的把分布式数据库当作一个单库来使用——除非你完全不在乎跨片的性能损耗。

    但分布式中间件也确确实实有很大的作用,它极大的减少了业务的改造量,也保证了了分布式事务的ACID特性。在各类分布式中间件迭代发展的过程中,这一技术路线也在逐渐进步:厂家开始探索对底层数据库的改造,以使其更适应分布式特性;中间件层也吸收了后面NewSQL的一些技术思路,在全局事务管理、数据增量写入等方面做了很多优化。

    普通分布式中间件

    大部分分布式中间件的架构一般有以下三个部分:

    客户端:通常为MySQL5.7或8.0版本的客户端,支持JDBC访问。
    存储层:由多个MySQL实例组成,引擎为InnoDB。
    计算层(中间件层):组织并管理存储层的MySQL实例,接受并解析客户端传来的SQL请求。计算层通常用片的概念把存储层的MySQL分割,然后以片为单位进行多副本来实现高可用。计算层显式或隐式的有一个事务管理组件,负责给事务赋一个全局唯一的ID,这个组件是实现分布式事务一致性的一种重要的解决方案。计算层对客户端屏蔽多副本和事务ID,会对客户端发来的普通SQL进行拆分和改造,并生成分布式的执行计划,然后下发到存储层的MySQL实例执行。

    阿里OceanBase数据库

    OceanBase的总体架构如下图。
    在这里插入图片描述
    可以看到OceanBase主要由五部分组成:
    客户端:用户使用OceanBase的方式和MySQL数据库完全相同,支持JDBC、C客户端访问等。
    RootServer:管理集群中的所有服务器,子表(tablet)数据分布以及副本管理。RootServer一般为一主一备,主备之间由数据强同步。
    UpdateServer:存储OceanBase系统的增量更新数据。UpdateServer一般为一主一备,主备之间可以配置不同的同步模式。部署时,UpdateServer进程和RootServer进程往往共用物理服务器。
    ChunkServer:存储OceanBase系统的基线数据。基线数据一般存储两份或者三份,可配置。
    MergeServer:接收并解析用户的SQL请求,经过词法分析、语法分析、查询优化等一系列操作后转发给响应的ChunkServer或者UpdateServer。如果请求的数据分布在多台ChunkServer上,MergeServer还需要对多台ChunkServer返回的结果进行合并。
    OceanBase借鉴了BigTable的做法,相比于普通的分布式中间件引入了UpdateServer这种增量更新机制,在不需要使用两阶段提交的情况下实现了分布式事务,这点下一篇分布式事务部分会详细展开。

    第二代分布式数据库——NoSQL

    在早期分库分表方案发展过程中,好多公司都面临了因扩容而无限次改造业务的痛苦。他们再次观察业务,发现业务并不复杂——至少没复杂到需要使用高级SQL的地步。这样NoSQL干脆就抛弃了高级SQL(分布式ACID特性),从而换来对业务透明的特性和强水平扩展的能力。

    这样做的好处显而易见——只要你能忍受不用高级SQL这一点,那么你只要进行一次到NoSQL的改造,后面就可以近乎无限的扩容,无需任何业务的适配。

    各种NoSQL,如HBase,Cassandra,Leveldb,RocksDB底层的数据结构,都是LSM-Tree。

    因为NoSQL不支持分布式ACID特性,和其他分布式数据库差别较大,所以不列入后面对事务的讨论。

    第三代分布式数据库——NewSQL

    上面的分库分表、分布式中间件和NoSQL都不可避免的由一个业务侵入性的问题,有些前沿厂家就产生了把二者结合起来,设计一个兼具分布式事务一致性和强可扩展性的数据库的想法——这就是NewSQL的诞生。

    在NewSQL领域,有两个流派,分别是Amazon的Aurora和Google的Spanner。这两者之前的区别实际上是非常大的,所以我们在后文中也把他们看作两种完全不同的数据库。

    Aurora流派

    Aurora流派也被称作Shared Everything,目前这个流派,多是被部署到虚拟计算环境中的云数据库,本文涉及的云数据库有阿里的PolarDB,Amazon的Aurora以及华为云数据库Taurus。

    知乎上有个很有意思的问题:为什么AWS云计算服务是亚马逊先做出来,而不是Google?

    这个问题的回答也都很专业,这里简单总结一下。Amazon的核心业务电子商务有太强的季节性,可以理解成,Amazon要维持的服务器数量是根据每年黑五的需求决定的,而一年的其他时间完全不需要这么多服务器。于是就诞生了AWS的想法,也成为后来“云”这一概念的雏形。
    另外还有一点就是两者商业哲学的不同。Amazon更倾向于提供近似于水电的基础设置服务,成本应该越低越好,价格也应该越低越好;而Google零几年的时候主营的业务广告利润非常之高,并且Google一向只喜欢提供终端的服务,既没有压力也没有动力去做云。

    Aurora流派最重要的一个概念就是Log is Database。这个概念是把log写到存储层,由存储层负责重放log、回写page并尽量减少写放大。

    下面一个表格列出了Aurora一系列数据库的特性对比.

    数据库计存分离解决方案架构特点架构缺点
    PolarDB将InnoDB的log和page存放带类POSIX接口的分布式文件系统CPU负载小;采用基于RDMA实现的ParallelRaft技术来复制数据;对于InnoDB的侵入非常小,便于跟进MySQL社区的新版本Page刷脏网络压力大;
    AuroraLog is Database将db的数据(也就是所有的page)分成若干个10GB大小的shard,相应的log也随data一起保存在shard中;持久化、page读取都只需要一跳网络传输。存储节点需要大量的CPU做redo log到innodb page的转换
    SocratesLog is Database相比于Aurora单独了一个log层用于持久化log,避免受到重放log、回写page的影响;PageServer层从log层拉取log进行重放、回写page,并向计算节点提供读取page服务。存储节点需要大量的CPU做redo log到innodb page的转换
    CynosDBLog is Database相比于Aurora存储层为计算节点提供了Log IO接口与Page IO接口,前者负责持久化log,后者负责page的读取存储节点需要大量的CPU做redo log到innodb page的转换
    TaurusLog is Database有独特的Log Store设计;使用了raft复制协议存储节点需要大量的CPU做redo log到innodb page的转换

    需要专门说明的一点是Aurora和PolarDB理念上的区分。Aurora认为网络会成为云数据库的瓶颈;PolarDB则认为网络传输速度会快速发展,后续软件代码(CPU)才是性能的瓶颈。

    这两种思路的区别导向了两种架构。Aurora的设计是日志即数据,在保证日志落盘的前提下,尽量减少磁盘IO,所以整个Aurora只写一份Redo log到底层存储,由底层存储来实现把rodo log‘恢复’成数据页的行为;PolarDB则把数据页和rodo log都写入底层存储,PolarDB的底层存储PolarStore更像一个通用的高可用存储,不需要进行类似Aurora一样把Redo日志恢复出数据文件的操作。

    从同行的表现来看,后面一系列的云原生数据库基本都跟进了Aurora的架构,看起来还是Log is Database架构更合理。不过,也有一种说法是PolarDB在早期没有过分考虑技术的长远性,而是直接选择一种易实现的架构来抢占市场。从这种角度看,PolarDB是成功的。

    华为云Taurus数据库

    我们这里以2020年六月份华为云Taurus在Sigmod上发表的论文来看一下Aurora流派的结构。下图是Taurus的结构图。
    在这里插入图片描述
    可以看到Taurus主要由四部分组成:

    客户端:目前是一个改版的MySQL8.0;
    SAL:全称Storage Abstraciton Layer,可以理解为存储层的前端和存储数据分布式管理组件,负责DB引擎与存储的Log Store/Page Store交互,同时也负责创建、管理、删除Page Store的Slices以及管理page在Slices上的映射关系;
    Log Store:负责持久化log以及为只读实例提供log内容;
    Page Store:存储真正的数据并为SQL前端提供page读取服务,向SAL提供4个API:WriteLogs,ReadPage,SetRecycleLSN,GetPersistentLSN。

    阿里双十一存储引擎X-Engine

    X-Engine是阿里专为双十一设计的存储引擎,因为其特殊性,我们这里也简单介绍以下它的架构。我们可以从2019年阿里发布的论文《X-Engine:An Optimized Storage Engine for Large-scale E_commerce Transaction Processing》中看到其具体的设计。

    X-Engine主要是为了解决双十一面临的三个问题而研发的,这三个问题是:

    海啸问题,活动开始时每秒交易量(TPS)激增;
    泄洪问题,缓存很快被大量数据填满;
    访问热点急速变化问题,随着促销活动的改变,数据的冷热会发生迅速的切换。

    这种特殊的场景使X-Engine相比于其他的分布式数据库更加重视insert和update性能,从而使用了具有杰出写入性能的LSM-Tree这种数据结构。

    X-Engine的架构见下图。(大家可以对照上文普通LSM-Tree的结构图)
    在这里插入图片描述

    基于LSM-Tree分层存储能够做到写的高吞吐,带来的副作用是整个系统必须频繁的进行compaction,写入量越大,Compaction操作越频繁。而Compaction操作非常消耗CPU和IO,在高吞吐的情况下,大量的Compaction操作占用大量系统资源,必然带来整个系统性能断崖式下跌,对应用系统产生巨大影响。

    X-Engine为了优化这个问题,引入了异构硬件设备FPGA来代替CPU完成compaction操作,使系统整体性能维持在高水位并避免抖动,是存储引擎得以服务业务苛刻要求的关键。

    Spanner流派

    Spanner流派也称作Shared Nothing。与分布式中间件不同的是,它是从分布式系统出发,再来做存储,做查询,利用天然的扩展能力和列存的性能优势,实现基于KV存储的支持关系型查询的数据库。如TiDB,就是一个NewSQL的商业化的实现。

    我们对Spanner的所有了解都来自Google于2012年发表的论文《Spanner: Google’s Globally-Distributed Database》。

    Spanner论文中有两个点需要十分重视:一个是TrueTime API的实现,给Spanner提供了全局的时钟接口,在此基础上Spanner才能实现强的全局一致性保证;另一个是论文中对Spanner的分布式事务实现细节进行了详细的描述。第一点在本文中会有详细的阐述,第二点详见下一篇分布式事务部分。
    Spanner的总体(全球)架构见下图。
    在这里插入图片描述
    universe是Spanner的全球部署实例,并被分成多个zone,zone是Spanner管理部署和物理隔离的单元。
    一个zone包含一个zonemaster,若干个location proxy,和一百至几千个spanserver。zonemaster把数据分配给spanserver,spanserver把数据提供给客户端。客户端使用每个zone上面的location proxy来定位可以为自己提供数据的spanserver。

    spanserver的架构见下图。
    在这里插入图片描述
    每个spanserver负载管理了100到1000个tablet(BigTable提出的一种数据结构),tablet实现了下面的映射:

    (key:string,timestamp:int64) -> string

    为了支持复制,每个spanserver会在每个tablet上面实现一个单个的Paxos状态机。Paxos协议会选举出一个领导者(上图中中间的那个replica),写操作必须在领导者上初始化Paxos协议,读操作可以直接从底层任何副本的tablet中访问状态信息,只要这个副本足够新。副本的集合称为一个Paxos group。

    此外,Spanner实现分布式事务一致性是靠两阶段提交,所以一个分布式事务还会选举出一个participant leader。transaction manager就是用来实现participant leader的。

    lock table则用来实现并发控制,这个锁表包含了两阶段锁机制的状态:它把键的值域映射到锁状态上面。

    下图是Spanner TrueTime的三个API。
    在这里插入图片描述
    TrueTime会显式地把时间表达成TTinterval,这是一个时间区间,具有有界限的时间不确定性。

    TT.now()返回的结果是当前时间的一个闭区间[earliest,latest]。用函数tabs(e)表示一个事件e的绝对事件,那么对于一个调用tt=TT.now(),TrueTime可以保证tt.earliest <= tabs(e) <= tt.latest。

    底层上,TrueTime使用GPS和原子钟两种方式来获取时间,增加可靠性。在Google的线上应用环境中,TrueTime的误差边界是一个关于时间的锯齿形函数,在1到7ms之间变化,其中1ms来自网络通讯延迟。

    总结

    本文从分布式的概念出发,阐述笔者理解的分布式数据库三个发展阶段,并分别介绍每个阶段的代表性的数据库及其架构,主要包括普通分布式中间件、OceanBase、华为云Taurus、X-Engine引擎和Spanner。下一篇,我会详解这些分布式数据库分布式事务的的实现。

    展开全文
  • 《分布式数据库架构及企业实践——基于Mycat中间件》由资深 Mycat 专家及一线架构师、DBA 编写而成。全书总计 8 章,首先简单介绍了分布式系统和分布式数据库的需求,然后讲解了分布式数据库的实现原理,并对市场上...
  • 架构师大会-可扩展数据库架构
  • MySQL 数据库架构全掌握
  • 数据库架构的演变

    千次阅读 2022-01-05 14:44:06
    关系型数据库发展历程中,经历了如下几种架构的变化: 2. 单机架构 包括应用服务和数据库放在同一台服务器,以及将应用服务和数据库服务分开部署两种方式,后一种方式可以通过增加服务器数量来进行负载均衡,增加...

    1. 概述

    关系型数据库发展历程中,经历了如下几种架构的变化:


    在这里插入图片描述


    2. 单机架构

    单机架构分为以下两种模式


    在这里插入图片描述

    包括应用服务和数据库放在同一台服务器,以及将应用服务和数据库服务分开部署两种方式,后一种方式可以通过增加服务器数量来进行负载均衡,增加系统的并发能力。

    优点:

    ● 集中部署
    ● 便于运维

    缺点:

    ● 可扩展性差:单机性能的提升存在瓶颈
    ● 存在单点故障:扩容时需要停机,硬件故障会导致整个服务不可用,甚至数据丢失


    3. 主备架构

    数据库部署到两台服务器上,主机承担数据读写服务,备机利用数据同步机制进行数据同步,保证和主机之间的数据一致性。同一时刻,只有一台服务器对外提供服务。


    在这里插入图片描述

    优点:

    ● 具有一定的抵御故障的能力
    ● 提升了数据的容错性

    缺点:

    ● 资源浪费:无故障时只会使用主机,备机的资源长时间无法利用
    ● 性能压力集中于主机,无法解决性能瓶颈问题
    ● 故障时需要人工干预


    4. 主从架构

    主机角色和主备模式中的主机一致,从机也对外提供一定的服务,通过读写分离模式分散服务压力。其中,主机负责写操作,从机负责数据查询服务。


    在这里插入图片描述

    优点:

    ● 提升资源利用率,适合读多写少的场景
    ● 在大并发读的场景,可使用负载均衡在多个从机间进行平衡
    ● 从机扩展灵活,扩容操作不影响业务

    缺点:

    ● 延迟问题,数据同步到从机数据库时会有延迟,存在暂时的数据不一致性
    ● 写操作的性能压力还是集中在主机上
    ●主机故障时需要主从切换,人工干预需要响应时间,自动切换复杂度较高


    5. 多主架构

    数据库服务器互为主从,同时对外提供服务。


    在这里插入图片描述

    优点:

    ● 资源利用率较高的同时降低了单点故障的风险。

    缺点:

    ● 双主机都接受写数据,要实现数据双向同步。双向复制同样会带来延迟问题,极端情况下有可能数据丢失
    ● 数据库数量增加会导致数据同步问题变得极为复杂,实际应用中多见双机模式


    6. 共享存储多活

    多个主节点共享存储资源的一种模式,多主又实现了负载均衡。


    在这里插入图片描述

    优点

    ● 高可用,可伸缩性好
    ● 避免了服务器集群的单点故障问题

    缺点

    ● 实现技术难度大
    ● 横向扩展时,存储IO容易成为整个系统的性能瓶


    7. 分片

    表现为数据水平分片,把数据分散到多个节点上,每个分片包含数据库的一部分,称为一个shared。节点之间的数据库结构相同,但保存的数据没有交集,所有分片的并集为数据总体。
    分片的算法常见的有:根据列表值、范围取值和hash值等。


    在这里插入图片描述

    优点:

    数据分散到集群的各个节点上,所有节点可以独立工作。


    8. MPP架构

    MPP(Massively Parallel Processing)称为大规模并行处理,将计算任务并行的分散到多个服务器和节点上,当每个节点计算完成之后,再将各自部分的结果汇总计算得到最终的结果。


    在这里插入图片描述

    它的特点在于计算任务可以并行执行,极大的提高了计算的效率。市场上常见的MPP架构的产品有:

    • 无共享Master:Vertica、Teradata
    • 共享Master:Greenplum、Netezza

    其中无共享Master的模式所有节点是对等的,应用可以通过任意一个节点来查询或加载数据,不存在性能瓶颈和单点故障问题


    8. 总结

    各种架构模式的对比如下:


    在这里插入图片描述

    展开全文
  • 淘宝数据库架构演进历程
  • 大型数据库案例_阿里数据库架构变迁与展望 共22页.pdf
  • TalkingData-大数据统计分析平台架构故事-数据库技术进化 数据库架构变迁 共28页.pptx

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 907,591
精华内容 363,036
关键字:

数据库架构