[架构之路-130]-《软考-系统架构设计师》-数据库-2-数据库的事务性控制与数据
Posted 文火冰糖的硅基工坊
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了[架构之路-130]-《软考-系统架构设计师》-数据库-2-数据库的事务性控制与数据相关的知识,希望对你有一定的参考价值。
前言:
第13章 数据库
第4节 数据库的事务性控制
4.1 并发控制的基本概念
在计算机科学,特别是程序设计、操作系统、多重处理和数据库等领域,并发控制是确保及时纠正由并发操作导致的错误的一种机制。并发控制的基本单位是事务。
并发控制指的是当多个用户同时更新运行时,用于保护数据库完整性的各种技术。
并发机制不正确可能导致脏读、幻读和不可重复读等此类问题。
并发控制的目的是保证一个用户的工作不会对另一个用户的工作产生不合理的影响。在某些情况下,这些措施保证了当用户和其他用户一起操作时,所得的结果和她单独操作时的结果是一样的。
在另一些情况下,这表示用户的工作按预定的方式受其他用户的影响。
(1)原子性(Atomicity)
原子性:指事务的不可分割性,一个事务的所有操作要么不间断地全部被执行,要么一个也没有执行。
一个原子事务要么完整执行,要么干脆不执行。
这意味着,工作单元中的每项任务都必须正确执行。如果有任一任务执行失败,则整个工作单元或事务就会被终止。即此前对数据所作的任何修改都将被撤销。如果所有任务都被成功执行,事务就会被提交,即对数据所作的修改将会是永久性的。`
(2)一致性(Consistency)
一致性代表了底层数据存储的完整性。
它必须由事务系统和应用开发人员共同来保证。事务系统通过保证事务的原子性,隔离性和持久性来满足这一要求;
应用开发人员则需要保证数据库有适当的约束(主键,引用完整性等),并且工作单元中所实现的业务逻辑不会导致数据的不一致(即,数据预期所表达的现实业务情况不相一致)。
例如,在一次转账过程中,从某一账户中扣除的金额必须与另一账户中存入的金额相等。
(3)隔离性(Isolation)
隔离性意味着事务必须在不干扰其他进程或事务的前提下独立执行。
换言之,在事务或工作单元执行完毕之前,其所访问的数据不能受系统其他部分的影响。
(4)持续性/持久性(Durability)
持续性表示在某个事务的执行过程中,对数据所作的所有改动都必须在事务成功结束前保存至某种物理存储设备。这样可以保证,所作的修改在任何系统瘫痪时不至于丢失。
4.2 并发引发的问题
(1)丢失更新
(2)不可重复读
(3)读脏数据
4.2 并发问题的解决办法:封锁协议
第5节 数据库完整性约束
5.1 数据库约束
5.2 数据库的安全性
5.3 数据库的备份
5.4 数据库故障与恢复
第6节 分布式数据库
6.1 背景
自从互联网进入了 web2.0 时代以来,数据库作为核心的底层基础设施软件也经历了蓬勃的发展期,从早期的单机关系型数据库到NoSQL 再到如今的 NewSQL,数据库领域不管是技术还是场景都发生了巨大的变化。在当下云原生时代,任何软件系统拥有分布式能力似乎成了标配。
特别是在目前基础软件国产化的浪潮下,国产数据库百花齐放,大有弯道超车的趋势。
在这个领域里面,分布式数据库无疑是当今最热门的赛道,本期就带大家来了解什么是分布式数据库。
6.2 什么是分布式数据库
分布式数据库系统 (DDBS)包含分布式数据库管理系统(DDBMS)和分布式数据库(DDB)。在分布式数据库系统中,一个应用程序可以对数据库进行透明操作,数据库中的数据分别在不同的局部数据库中存储、由不同的 DBMS进行管理、在不同的机器上运行、由不同的操作系统支持、被不同的通信网络连接在一起。
分布式数据库系统通常使用较小的计算机系统,每台计算机可单独放在一个地方,每台计算机中都可能有DBMS的一份完整拷贝副本,或者部分拷贝副本,并具有自己局部的数据库,位于不同地点的许多计算机通过网络互相连接,共同组成一个完整的、全局的逻辑上集中、物理上分布的大型数据库。
以大家非常熟悉的场景举例,比如完成一项软件开发工作:
小公司的做法就是招一个全栈工程师,所有任务全包,但往往这样的人虽然各方面都懂一点却没有特别精通的方向,很容易达到能力上限。称为单体数据库。
在一个大团队通常会分为多种角色(UI、前端、后端、DBA、运维等),这些人就构成了一个分布式系统,大家协调完成共同的任务,这中间的协调者就是项目经理或者部门 leader。
分布式数据库的好处:
• 职责分离:大家各司其职,各自做好擅长的事。
• 平滑扩容:哪个环节缺人就定点补充。
• 负载能力:可以应对更大更多的项目。
当然了有优点就有缺点:
• 网络通信:沟通成本增加,需要标准化工作模式。
• 调度:如何高效率协调所有人员。
• 一致性:如何保证上下游人员信息对齐。
分布式数据库最早于 20 世纪 80 年代提出,受限于当时 的计算机软硬件及网络发展水平,数据库专家 M.Tamer Özsu 和 Patrick Valduriez 在经典著作《分布式数据库系统原理(第 3 版)》中,把分布式数据库定义为一群分布在计算机网络上、 逻辑上相互关联的数据库。
随着信息技术的发展,集中式数据库也正向基于网络的共享集群路线发展,而市场上的分布式数据库也不仅限于网络分布、逻辑关联等特性,经典的分 布式数据库定义显然已不能体现分布式数据库当前技术特 点,难以满足数据库种类区分要求。
根据目前我国分布式数据库技术现状,我们认为分布式 数据库是具备分布式事务处理能力、可平滑扩展、分布于计 算机网络且逻辑上统一的数据库。
主要特征如下:
分布式事务处理
分布式数据库与集中式数据库的主要区别就是是否具备分布式事务的处理能力。通过对数据库各种操作的并行计算、全局事务管理等机制,实现真正的分布式事务处理,并实现与集中式数据库一致的ACID 特性。
平滑扩展
分布式数据库可根据业务的增长需要, 动态扩展物理节点,以提升整体处理能力,且扩展过程不需停机,不影响在线业务。理论上可以进行无限扩展,扩展之 后在逻辑上仍然是一个统一的数据库。
物理分布、逻辑统一
分布式数据库的数据不是存储在一个物理节点中,而是存储在计算机网络上的多个节点 上,且通过网络实现了真正的物理分布。而逻辑上仍是一个 数据库(这是集群数据库一个显著的区别),为用户提供统一的访问入口,实现对分布在网络节 点上的数据的统一操作,即用户可以像使用传统集中式数据 库一样使用分布式数据库,而不是分别操作多个数据库。
6.3 分布式与集群的区别
说到分布式就不得不提与之相关的另一个概念,那就是集群,很多初学者并不能很好的理解集群和分布式的差别。
还是拿前面的例子来说,假如小公司的全栈工程师有点异常情况(请假、跑路、忙不过来等等)老板会考虑招多个这样的全栈人员,这就形成了一个集群,好处就是能干更多的活(负载分流)和互补(高可用),但本质上还是一个人做所有事。
事实上,分布式和集群是可以搭配使用的,比如上面的大团队例子,每个角色可以配置多个相同技能的人,这就形成了分布式集群。
6.4 分布式数据库常用的三种存储架构设计模型
(1)shared-Everything
一般针对于单机而言,完全透明的共享 CPU、内存和IO等资源,并行能力是三种结构中最差的。
(2)shared-Disk
shared-disk也可以成为shared-storage,每个单元的CPU和内存是独立的,共享磁盘系统,典型产品有Oracle RAC,它是数据共享,可以通过增加节点来提高并行处理能力,扩展能力较好。当存储器接口达到饱和时,增加节点并不能获得更高的性能。
aurora采用了share storage, shared-storage同样可以解决 ha 和快速恢复(甚至比选举还快),特别是对于云厂商可以一个大 storage 给多个租户,对用户便宜对自己省钱。
(3)shared-Nothing
每个处理单元所拥有的资源都是独立的,不存在共享资源。
单元之间通过网络协议通信,并行处理和扩展能力更好。各个节点相互独立,各自处理自己的数据,处理后的结果可能向上层汇总或者节点间流转。
目前包括国内OceanBase、TiDB都采用了Shared-Nothing架构。
Shared-Nothing架构的优势:
易于扩展
内部自动并行处理,无需人工分区或优化
最优化的IO处理
增加节点实现存储、查询及加载性能的线性扩展
6.5 存算分离
相信今天很多人都听过存储与计算分离,但不同系统的做法差别很大。
业界有三种存储计算分离方案:
6.5.1 中间件分库分表
基于中间件分库分表,后端的数据库表示存储,中间件表示计算,这种方案是真正的存储计算分离吗?显然不是,我也把这种方案叫做“伪存储计算分离”,主要有以下两种模式:
(1)客户端程序库方式
该方式在客户端安装程序库,通过客户端程序库直接访问数据,该方式的优点是性能高,缺点是对应用有侵入。访问示意图如下:
典型客户端程序库中间件如阿里的TDDL,本文以TDDL为例,介绍客户端程序库方式的数据库访问中间件的工作原理。
TDDL采用了客户端库(即Java.jar包)形式,在Jar包中封装了分库分表的逻辑,部署在ibatis、mybatis或者其他ORM框架之下、JDBC Driver之上,是JDBC或持久框架层与底层JDBC Driver之间的交互桥梁。
TDDL的逻辑架构分为三层:Matrix 、Group、Atom。Matrix层负责分库分表路由,SQL语句的解释、优化和执行,事务的管理规则的管理,各个子表查询出来结果集的Merge等;Group层负责数据库读写分离、主备切换、权重的选择、数据保护等功能;Atom层是真正和物理数据库交互,提供数据库配置动态修改能力,包括动态创建,添加,减少数据源等。
当client向数据库发送一条SQL的执行语句时,会优先传递给Matrix层。由Martix 解释 SQL语句、优化,并根据查询条件将SQL路由到各个group;各个group根据权重选择其中一个Atom进行查询;各个Atom再将结果返回给Matrix,Matrix将结果合并返回给client。:
6.6 分布式数据库四层模式
4层模式划分为全局外层、全局概念层、局部概念层和局部内层,在各层间还有相应的层间映射。
这种4层模式适用于同构型分布式数据库系统,也适用于异构型分布式数据库系统。
分布式服务器主要是用来解决,单一个服务器处理能力的限制:
CPU处理能力的限制
内存容量的限制
分布式服务器,是通过把数据库的部分内容分散到不同的服务器上,实现分布式存储。
第7节 其他数据库
7.1 联邦数据库
7.2 非SQL数据库
扩展,也称为伸缩性,指的系统不断增加其承载能力的能力。
数据库的扩展可以简单分为两类:
向上扩展:是提高硬件性能,买更好的服务器,这种方式比较简单,一般情况下向上扩展就可以解决问题,但是如果代价太大了(规格越高的硬件需要花费的钱越多),就不可取了。而且向上扩展总有极限的。
横向扩展(水平扩展):是通过副本(读写分离)、垂直切分水平切分的方式,把不同的数据放在不同的节点(物理部署的mysql实例)中。
读写分离:给数据库(主数据库)增加一个从数据库,主数据库负责文本的写操作(增,删,改),从数据库负责数据读的操作,如下图所示。也可以一主多从(一个主数据库,多个从数据库),不过需要进行负载均衡。
垂直切分:按照功能模块划分数据,举一个例子:一个电商网站,数据库中可能有库存管理的数据,用户管理的数据,订单管理的数据,他们属于不同的功能,可以将一个数据库分成三个数据库,库存管理的数据库,用户管理的数据库,订单管理的数据数据库。
不同数据库存放的是相同用户,不同特征的数据!!!
水平切分:将同一个表中的数据进行分片保存到不同的数据库中。例如:一个用户表,我们可以将用户分片保存的不同的数据库中,可以根据 用户的ID(userID),userID%3==0的用户放到一个库中,userID%3==1 放到一个库中,userID%3==2放到一个库中,如下图所示。
不同数据库存放的是相同特征,不同用户的数据数据!!!
7.3 内存数据库
7.4 数据仓库与数据挖掘
7.4.1 什么是数据仓库?
数据仓库是一个面向主题的( Subject Oriented) 、集成的( Integrate) 、相对稳定的(NonVolatile) 、反映历史变化( Time Variant)的数据集合,用于支持管理决策。对于数据仓库的概念我们能够从两个层次予以理:
①数据仓库用于支持决策,面向分析型数据处理,它不同于企业现有的操作型数据库;
②数据仓库是对多个异构数据源的有效集成,集成后依照主题进行了重组,并包括历史数据,并且存放在数据仓库中的数据一般不再改动。企业数据仓库的建设是以现有企业业务系统和大量业务数据的积累为基础。数据仓库不是静态的概念,仅仅有把信息及时交给须要这些信息的使用者,供他们作出改善其业务经营的决策,信息才干发挥作用,信息才有意义。而把信息加以整理、归纳和重组,并及时提供给对应的管理决策人员是数据仓库的根本任务。
7.4.2 为什么要建立数据仓库?
企业建立数据仓库是为了填补现有数据存储形式已经不能满足信息分析的须要。数据仓库理论中的一个核心理念就是:事务型数据和决策支持型数据的处理性能不同。
企业在它们的事务操作收集数据。在企业运作过程中:随着定货、销售记录的进行,这些事务型数据也连续的产生。为了引入数据,我们必须优化事务型数据库。
处理决策支持型数据时,一些问题常常会被提出:哪类客户会购买哪类产品?促销后销售额会变化多少?价格变化后或者商店地址变化后销售额又会变化多少呢?在某一段时间内,相对其它产品来说哪类产品特别easy卖呢?哪些客户添加了他们的购买额?哪些客户又削减了他们的购买额呢?
事务型数据库能够为这些问题作出解答,可是它所给出的答案往往并不能让人十分惬意。在运用有限的计算机资源时经常存在着竞争。在添加新信息的时候我们须要事务型数据库是空暇的。而在解答一系列详细的有关信息分析的问题的时候,系统处理新数据的有效性又会被大大减少。还有一个问题就在于事务型数据总是在动态的变化之中的。决策支持型处理须要相对稳定的数据,从而问题都能得到一致连续的解答。
数据仓库的解决方法包含:将决策支持型数据处理从事务型数据处理中分离出来。数据依照一定的周期(通常在每晚或者每周末),从事务型数据库中导入决策支持型数据库——既“数据仓库”。数据仓库是按回答企业某方面的问题来分“主题”组织数据的,这是最有效的数据组织方式。
另外,企业日常运作的信息系统通常是由多个传统系统、不兼容数据源、数据库与应用所共同构成的复杂数据集合,各个部分之间不能彼此交流。从这个层面看:眼下执行的应用系统是用户花费了非常大精力和財力构建的、不可替代的系统,特别是系统的数据。而建立数据仓库的目的就是要把这些不同来源的数据整合组织起来统一管理,从而做到数据的一致性与集成化,提供一个全面的,单一入口的解决方式。这个让我联想到SOA的理念,只是前者是数据层面的整合优化,后者是应用服务层面的整合优化。
7.4.3 数据挖掘
数据挖掘通常与计算机科学有关,并通过统计、在线分析处理、情报检索、机器学习、专家系统(依靠过去的经验法则)和模式识别等诸多方法来实现上述目标。
数据挖掘是人工智能和数据库领域研究的热点问题,所谓数据挖掘是指从数据库的大量数据中揭示出隐含的、先前未知的并有潜在价值的信息的非平凡过程。数据挖掘是一种决策支持过程,它主要基于人工智能、机器学习、模式识别、统计学、数据库、可视化技术等,高度自动化地分析企业的数据,作出归纳性的推理,从中挖掘出潜在的模式,帮助决策者调整市场策略,减少风险,作出正确的决策。知识发现过程由以下三个阶段组成:①数据准备;②数据挖掘;③结果表达和解释。数据挖掘可以与用户或知识库交互。
数据挖掘是通过分析每个数据,从大量数据中寻找其规律的技术,主要有数据准备、规律寻找和规律表示三个步骤。数据准备是从相关的数据源中选取所需的数据并整合成用于数据挖掘的数据集;规律寻找是用某种方法将数据集所含的规律找出来;规律表示是尽可能以用户可理解的方式(如可视化)将找出的规律表示出来。数据挖掘的任务有关联分析、聚类分析、分类分析、异常分析、特异群组分析和演变分析等。
第8节 数据库性能的优化
8.1 性能优化的手段
8.2 大数据
以上是关于[架构之路-130]-《软考-系统架构设计师》-数据库-2-数据库的事务性控制与数据的主要内容,如果未能解决你的问题,请参考以下文章
[架构之路-111]-《软考-系统架构设计师》-软件架构设计-4-特定领域软件架构
[架构之路-109]-《软考-系统架构设计师》-软件架构设计-2-软件架构概述:架构风格
[架构之路-118]-《软考-系统架构设计师》-软架构设计-11-可靠性相关设计
[架构之路-110]-《软考-系统架构设计师》-软件架构设计-3-架构描述语言ADL与UML