关系型数据库架构介绍及主流应⽤场景
前⾔
做为⽬前主流的模型数据库类型，关系型数据库的架构随着业务规模的增长做出相应的变化，本章我们来学习关系型数据库架构的变化以及主流的应⽤场景。
关系型数据库架构
随着业务规模增⼤，数据库存储的数据量和承载的业务压⼒也不断增加，数据库的架构需要随之变化，为上层应⽤提供稳定和⾼效的数据服务。
上图所⽰的数据库架构中单机与多机的区别是按照主机数量进⾏区分，这⾥的主机指的是数据库服务器。单机架构就是指单个数据库主机，在单机架构中⼜分为了单主机和独⽴主机，所谓的单主机指的是应⽤和数据库都放在⼀个主机上，这对主机的性能负担过重，因此有了独⽴主机，将应⽤和数据库分开，数据库就放在专门的数据库服务器上，应⽤就放在专门的应⽤型服务器上。
多机架构是通过增加服务器数量来提升整个数据库服务的可⽤性和服务能⼒，多级架构分为了分组和分⽚，分组指的是对每个服务器区分⾓⾊，这⾥分为了主备、主从、多主结构。不管是主备、主从还是多主结构本质上都是多个数据库结构相同，储存数据相同的服务器之间进⾏数据同步。⽽分⽚结构则是将数据按照算法分摊在各个节点上，每个节点维护⾃⼰的数据库数据。
单机架构
为了避免应⽤服务和数据库服务对资源的竞争，单机架构也从早期的单主机模式发展到数据库独⽴主机模式，把应⽤和数据服务分开。应⽤服务可以增加服务器数量，进⾏负载均衡，增⼤系统并发能⼒。
优点部署集中，运维⽅
便。
⼀个数据库即⼀个主机，对单机结构服务器进⾏维护很⽅便，但同样出现故障也很⿇烦。
缺点
可扩展性
数据库单机架构扩展性只有纵向扩展（Scale-up）。通过增加硬件配置来提升性能，但单台主机的硬件可配置的资源会遇到
上限。
存在单点故障扩容的时候往往需要停机扩容，服务停⽌。硬件故障导致整个服务不可⽤，甚⾄数据丢失。单机会遇到性能瓶颈。
早期互联⽹的LAMP（Linux，Apache，Mysql，PHP）架构的服务器就是最典型的单机架构的使⽤。单主机和独⽴主机的区别
多机架构
分组架构：主备
在主备架构中数据的读写都在⼀台设备上进⾏，这台设备叫做主机（Master），⽽另外⼀台设备被称为备机（Backup），备机在正常情况下不会被使⽤，只会进⾏主备直接数据的同步，当主机出现故障后，备机将替代主机的作⽤进⾏数据读写。同⼀时间内只有⼀台设备能够对外提供服务。
优
点
应⽤不需要针对数据库故障来增加开发量。相对单机架构提升了数据容错性。解决了单点故障情况。
缺点资源的浪费，备机和主机同等配置，但长期范围内基本上资源限制，⽆法利⽤。性能压⼒依旧在⼀台设备上，⽆法解决性能的瓶颈，当出现故障时主备
机切换需要⼀定的⼈⼯⼲预或者监控。
分组架构：主从
在主从结构中，主机依旧只能有⼀台，但是从机可以有多台，根据业务需求进⾏横向的扩展。应⽤在主机上进⾏写⼊、修改、删除操作，把查询请求分配到从机上，⽽从机与主机之间要进⾏数据的同步。
优点提升资源利⽤率，适合读多写少的应⽤场景。在⼤并发读的使⽤场景，可以使⽤负载均衡在多个主机间进⾏平衡。从机的扩展性⽐较灵活，扩
容操作不会影响到业务进⾏。
缺点延迟问题，数据同步到从机数据库时会有延迟，所以应⽤必须能够容忍短暂的不⼀致性。对于⼀致性要求⾮常⾼的场景是不适合的。写操作的性能压⼒还是集中在主机上。主机出现故障，需要实现主从切换，⼈⼯⼲预需要响应时间，⾃动切换复杂度较⾼。
使⽤读写分离⽅式，应⽤开发模式有时也需要进⾏调整：应⽤开发过程中药注意区分读写操作，读操作提交到主机，写操作提交到从机，近年来，不同的数据库产品都出现了中间件来⽀持读写分离，数据库中间件起到路由功能，会识别读请求和写请求，分别把读写操作分配到读库和写库上。如开源的mycat，vitness等。读多写少是相对⽽⾔，许多互联⽹应⽤场景是读的事务量远远⼤于写的事务量，读操作往往先成为性能瓶颈。另外写库出现故障期间，读库仍然可以对外提供服务，表现出“只读”服务，根据从机的数量可以分为⼀主⼀从和⼀主多从。从机数量越多，虽然能够提升数据库读的并发访
问量，但是从机之间的数据⼀致性问题也会带来⽐较多问题。主机出现故障，⾃动切换就要解决多台从机如何选举出新主机的问题。对⼀致性要求不⾼的应⽤：如互联⽹⾏业的社交⽹络应⽤，对⼀致性要求⾼的场景：与⾦融，计费相关的应⽤。
分组架构：多主
多主架构，也称为双活，多活架构，在多主架构中，每⼀台设备都不再区分从设备，都互为主从。每台设备都能对上提供服务。
优
点
资源利⽤率较⾼的同时降低了单点故障的风险。
缺点双主机都接受写数据，要实现数据双向同步。双向复制同样会带来延迟问题，极端情况下有可能数据丢失。数据库数量增加会导致数据同步问题变得极
为复杂，实际应⽤中多见双机模式。
互为主从模式下的数据同步机制更为复杂，所以数据延迟、丢失都由可能存在，所以对于⼀致性要求⾮常⾼的场景，不适合使⽤这种架构。共享存储多活架构
共享存储的多活架构（Shared Disk）是⼀种特殊的多主架构。数据库服务器共享数据存储，⽽多个服务器实现均衡负载。它解决了多主结构中的数据⼀致性问题，所有节点共享⼀个储存设备，因此不会出现数据不⼀致的问题。
优点多个计算服务器提供⾼可⽤服务，提供了⾼级别的可⽤性。可伸缩性，避免了服务器集的单点故障问题。⽐较⽅便的横向扩展能够增加整
体系统并⾏处理能⼒。
缺
点
实现技术难度⼤。当存储器接⼝带宽达到饱和的时候，增加节点并不能获得更⾼的性能，存储IO容易成为整个系统的性能瓶颈。shared disk较为成功的案例⽬前，有Oracle的RAC（Real Application Cluster）产品， 微软的SQL Server Failover Cluster 分⽚(Sharding)架构
分⽚架构主要表现形式就是⽔平数据分⽚架构，把数据分散在多个节点上的分⽚⽅案，每⼀个分⽚包括数据库的⼀部分，称为⼀个shard。多个节点都拥有相同的数据库结构，但不同分⽚的数据之间没有交集，所有分区数据的并集构成数据总体。
优点数据分散在集内的各个节点上，所有节点可以独⽴性⼯作。
GaussDB 100可以⽀持，单机，主备，主从的架构部署⽅式，分布式版本⽀持分⽚架构的部署⽅式。⽬前正在计划开发共享存储多活的架构。
⽆共享(Share-Nothing)架构
⽆共享架构⾮常类似共享式储存多活架构，主不过不再使⽤共享的储存，⽽是每个节点使⽤维护各⾃的独⽴CPU/内存/储存，不存在共享资源。各节点（处理单元）处理⾃⼰本地的数据，处理结果可以向上层汇总或者通过通信协议在节点间流转。节点是相互独⽴的，扩展能⼒强。整个集拥有强⼤的并⾏处理能⼒。
可以说明⼀下，在硬件发展到当前时代，⼀个节点或⼀个物理主机上可以部署多个处理单元，所以Shared-Nothing的最⼩单元可能不是物理节点，⽽是逻辑上的虚拟处理单元。⽐如⼀个物理主机具有4核CPU，部署的时候可以部署4个数据库实例，也就相当于拥有4个处理单元。
MPP架构 (Massively Parallel Processing)
⼤规模并⾏处理（Massively Parallel Processing）是将任务并⾏的分散到多个服务器和节点上，在每个节点上计算完成后，将各⾃部分的结果汇总在⼀起得到最终的结果。
分为了两种架构
⽆Master架构所有节点都对等，可以通过任意的节点查询和写⼊数据，不存在性能瓶颈以及单点故障问题，可以进⾏横向扩展。
共享Master架构Master对外提供服务，任务由各个节点并⾏计算处理，结果上交给Master。
常见的MPP产品
⽆共享Master Vertica，Teradata。
共享Master Greenplum，Netezza。
Teradata，Netezza是软硬件⼀体机，GaussDB 200，Greeplum，Vertica是软件版MPP数据库
数据库架构特点对⽐
关系型数据库主流应⽤场景
greenplum数据库
联机事务处理 (OnLine Transaction Processing)
OLTP是传统关系数据库的主要应⽤，⾯向基本的，⽇常的事务处理，例如银⾏储蓄业务的存取交易，转账交易等。业务量⼤，但是单个业务需要处理的数据量⼩，类似银⾏中的每⽇流⽔，都是些基本的信息赠，删，改，查操作。
特点：
⼤吞吐量：⼤量的短在线事务（插⼊、更新、删除），⾮常快速的查询处理。⾼并发，（准）实时响应。
典型的OLTP应⽤场景
零售系统、⾦融交易系统、⽕车机票销售系统、秒杀活动等。
事务

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。