1. 数据库的不同类型
1.1 常用的关系型数据库
- Oracle:功能强大,主要缺点就是贵
- MySQL:互联网行业中最流行的数据库,这不仅仅是因为MySQL的免费。可以说关系数据库场景中你需要的功能,MySQL都能很好的满足,后面详解部分会详细介绍MySQL的一些知识点
- MariaDB:是MySQL的分支,由开源社区维护,MariaDB虽然被看作MySQL的替代品,但它在扩展功能、存储引擎上都有非常好的改进
- PostgreSQL:也叫PGSQL,PGSQL类似于Oracle的多进程框架,可以支持高并发的应用场景,PG几乎支持所有的SQL标准,支持类型相当丰富。PG更加适合严格的企业应用场景,而MySQL更适合业务逻辑相对简单、数据可靠性要求较低的互联网场景。
1.2 NoSQL数据库(非关系型数据库)
- Redis:提供了持久化能力,支持多种数据类型。Redis适用于数据变化快且数据大小可预测的场景。
- MongoDB:一个基于分布式文件存储的数据库,将数据存储为一个文档,数据结构由键值对组成。MongoDB比较适合表结构不明确,且数据结构可能不断变化的场景,不适合有事务和复杂查询的场景。
- HBase:建立在HDFS,也就是Hadoop文件系统之上的分布式面向列的数据库。类似于谷歌的大表设计,HBase可以提供快速随机访问海量结构化数据。在表中它由行排序,一个表有多个列族以及每一个列族可以有任意数量的列。 HBase依赖HDFS可以实现海量数据的可靠存储,适用于数据量大,写多读少,不需要复杂查询的场景。
- Cassandra:一个高可靠的大规模分布式存储系统。支持分布式的结构化Key-value存储,以高可用性为主要目标。适合写多的场景,适合做一些简单查询,不适合用来做数据分析统计。
- Pika:一个可持久化的大容量类Redis存储服务, 兼容五种主要数据结构的大部分命令。Pika使用磁盘存储,主要解决Redis大容量存储的成本问题。
1.3 NewSQL数据库(新一代关系型数据库)
- TiDB:开源的分布式关系数据库,几乎完全兼容MySQL,能够支持水平弹性扩展、ACID事务、标准SQL、MySQL语法和MySQL协议,具有数据强一致的高可用特性。既适合在线事务处理,也适合在线分析处理。
- OceanBase:OceanBase是蚂蚁金服的数据库,OB是可以满足金融级的可靠性和数据一致性要求的数据库系统。当你需要使用事务,并且数据量比较大,就比较适合使用OB。不过目前OB已经商业化,不再开源。
2. 事务特性及事务类型
2.1数据库事务特性(ACID)
数据库共4个特性:
- 原子性:是指事务由原子的操作序列组成,所有操作要么全部成功,要么全部失败回滚。
- 一致性:是指事务的执行不能破坏数据库数据的完整性和一致性,一个事务在执行之前和执行之后,数据库都必须处以一致性状态。比如在做多表操作时,多个表要么都是事务后新的值,要么都是事务前的旧值。
- 隔离性:是指多个用户并发访问数据库时,数据库为每个用户执行的事务,不能被其他事务的操作所干扰,多个并发事务之间要相互隔离。事务的隔离级别我们稍后介绍。
- 持久性:是指一个事务一旦提交并执行成功,那么对数据库中数据的改变就是永久性的,即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。
2.2 事物并发问题与隔离级别
2.2.1 事务并发问题
- 脏读:脏读是指在一个事务处理过程里读取了另一个未提交的事务中的数据,例如,账户A转帐给B500元,B余额增加后但事务还没有提交完成,此时如果另外的请求中获取的是B增加后的余额,这就发生了脏读,因为事务如果失败回滚时,B的余额就不应该增加。
- 不可重复读:不可重复读是指对于数据库中某个数据,一个事务范围内多次查询返回了不同的数据值,这是由于在多次查询之间,有其他事务修改了数据并进行了提交。
- 幻读:是指一个事务中执行两次完全相同的查询时,第二次查询所返回的结果集跟第一个查询不相同。与不可重复读的区别在于,不可重复读是对同一条记录,两次读取的值不同。而幻读是记录的增加或删除,导致两次相同条件获取的结果记录数不同。
2.2.2 事务的四种隔离级别
可以用于解决这几种并发问题。如图右面,由上到下的4种隔离级别由低到高。
- 级别一读未提交:也就是可以读取到其他事务未提交的内容,这是最低的隔离级别,这个隔离级别下,前面提到的三种并发问题都有可能发生。
- 级别二读已提交:就是只能读取到其他事务已经提交的数据。这个隔离级别可以解决脏读问题。
- 级别三可重复读:可以保证整个事务过程中,对同数据的多次读取结果是相同的。这个级别可以解决脏读和不可重复读的问题。MySQL默认的隔离级别就是可重复读。
- 级别四串行化:这是最高的隔离级别,所有事务操作都依次顺序执行。这个级别会导致并发度下降,性能最差。不过这个级别可以解决前面提到的所有并发问题。
2.3 事务分类
共分5大类:
- 扁平化事务:在扁平事务中,所有的操作都在同一层次,这也是我们平时使用最多的一种事务。它的主要限制是不能提交或者回滚事务的某一部分,要么都成功,要么都回滚。
- 带保存点的扁平事务:为了解决第一种事务的弊端,就有了第二种带保存点的扁平事务。它允许事务在执行过程中回滚到较早的状态,而不是全部回滚。通过在事务中插入保存点,当操作失败后,可以选择回滚到最近的保存点处。
- 链事务:可以看做是第二种事务的变种。它在事务提交时,会将必要的上下文隐式传递给下一个事务,当事务失败时就可以回滚到最近的事务。不过,链事务只能回滚到最近的保存点,而带保存点的扁平化事务是可以回滚到任意的保存点。
- 嵌套事务:由顶层事务和子事务构成,类似于树的结构。一般顶层事务负责逻辑管理,子事务负责具体的工作,子事务可以提交,但真正提交要等到父事务提交,如果上层事务回滚,那么所有的子事务都会回滚。
- 分布式事务:是指分布式环境中的扁平化事务。
分布式事务中,常用的解决方案共4种:
- a.XA协议:是保证强一致性的刚性事务。实现方式有两段式提交和三段式提交。两段式提交需要有一个事务协调者来保证所有的事务参与者都完成了第一阶段的准备工作。如果协调者收到所有参与者都准备好的消息,就会通知所有的事务执行第二阶段提交。一般场景下两段式提交已经能够很好得解决分布式事务了,然而两阶段在即使只有一个进程发生故障时,也会导致整个系统存在较长时间的阻塞。三段式提交通过增加Pre-commit阶段来减少前面提到的系统阻塞的时间。三段式提交很少在实际中使用,简单了解就可以了。
- b.TCC:是满足最终一致性的柔性事务方案。TCC采用补偿机制,核心思想是对每个操作,都要注册对应的确认和补偿操作。它分为三个阶段:Try阶段主要对业务系统进行检测及资源预留;Confirm阶段对业务系统做确认提交。Cancel阶段是在业务执行错误,执行回滚,释放预留的资源。
- c.消息事务:第三种方案是消息一致性方案。基本思路是将本地操作和发送消息放在一个事务中,保证本地操作和消息发送要么都成功要么都失败。下游应用订阅消息,收到消息后执行对应操作。
- d.GTS/Fescar:阿里云中的全局事务服务GTS,对应的开源版本是Fescar。Fescar基于两段式提交进行改良,剥离了分布式事务方案对数据库在协议支持上的要求。使用Fescar的前提是分支事务中涉及的资源,必须是支持ACID事务的关系型数据库。分支的提交和回滚机制,都依赖于本地事务来保障。 Fescar的实现目前还存在一些局限,比如事务隔离级别最高支持到读已提交级别。
3. 数据库的范式
前关系数据库有六种范式:第一范式、第二范式、第三范式、巴斯-科德范式(BCNF)、第四范式和第五范式。范式级别越高对数据表的要求越严格。
第一范式要求最低,只要求表中字段不可用在拆分。
第二范式在第一范式的基础上要求每条记录由主键唯一区分,记录中所有属性都依赖于主键。
第三范式在第二范式的基础上,要求所有属性必须直接依赖主键,不允许间接依赖。
一般说来,数据库只需满足第三范式就可以了。
4. 非关系型数据库和关系型数据库的特点(优缺点)
RDS:
- 特点:
- 关系型数据库的最大特点就是事务的一数性;
- 关系型数据库,是指采用了关系模型来组织数据的数据库;
- 简单来说,关系模型指的就是二维表格模型,而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织
- 优点:
- 容易理解:二维表结构是非常贴近逻辑世界的一个概念,关系模型相对网状、层次等其他模型来说更容易理解
- 使用方便:通用的SQL语言使得操作关系型数据库非常方便,支持很多复杂操作
- 易于维护:丰富的完整性(实体完整性、参照完整性和用户定义的完整性)大大减低了数据冗余和数据不一致的概率
- 缺点:
- 为了维护一致性所付出的巨大代价就是其读写性能比较差
- 每次操作都要进行sql语句的解析,消耗较大
- 关系型数据库往往每一步都要进行加锁的操作,也造成了数据库的负担
- 固定的表结构会使数据的存储不灵活
- 高并发时,读写性能不足
- 特点:
NoSql:
- 特点:
- 使用键值对存储数据;
- 分布式;
- 一般不支持ACID特性;
- 非关系型数据库严格上不是一种数据库,应该是一种数据结构化存储方法的集合
- 优点:
- 高并发,读写能力强
- 基于键值对,数据没有耦合性
- 弱化数据结构一致性,使用灵活,容易扩展,每一个元组可以有不一样的字段,每个元组可以根据需要增加一些自己的键值对,不局限于固定的结构,可以减少一些时间和空间的开销。
- 存储数据的格式多样:支持文档、图片等等,而关系型数据库则只支持基础类型。
- 缺点:
- 通用性差,没有sql语句那样通用的语句,学习成本较高
- 不适合持久存储海量数据
- 没有外键关联、事务处理(这个不一定)等复杂的操作,所以只适合存储一些较为简单的数据。对于需要进行较复杂查询的数据,关系型数据库显的更为合适。
- 特点: