后端架构师必知必会系列:数据库设计与优化

发布于:2023-09-27 ⋅ 阅读:(84) ⋅ 点赞:(0)

作者:禅与计算机程序设计艺术

1.简介

数据库(Database)是现代信息技术中最重要的基础设施之一。作为后端工程师,我们每天都在处理各种各样的数据,如交易、销售、库存等数据。而数据库则是存储这些数据的重要工具。如何高效、快速地存储和查询数据,成为后端工程师面临的一项重要技能。

本系列将系统、全面地讲述数据库设计与优化知识,从理论到实践,为您提供一站式的学习资源。主要涉及以下主题:

  • 关系型数据库设计
  • SQL语言和性能优化
  • NoSQL数据库设计
  • 分布式数据库设计

欢迎收藏转发分享!

2.关系型数据库设计

2.1 关系模型概念

关系模型是一种用于组织和存储关系数据的集合。关系数据通常由表格化结构组成,表中的每个单元格表示一个实体或属性值,不同的实体用不同的行表示,相同属性的值也用不同的列表示。

关系模型通过三元组(tuple)来表示关系数据,即:

< T u p l e > = ( e n t i t y n a m e , a t t r i b u t e v a l u e , . . . ) <Tuple> = (entity_name, attribute_value,...) <Tuple>=(entityname,attributevalue,...)

其中,entity_name是一个实体的名称;attribute_value是一个或多个属性的值,可以是数字、字符串、日期等等。

例如,对于一个销售人员信息表,关系模型定义如下:

SalesmanID Name Age Department Salary HireDate
1 John 30 Marketing $15000 Jan 1, 2010
2 Jane 27 Finance $9500 Feb 1, 2011
3 Scott 40 Operations $16000 Jul 1, 2009

这里,SalesmanID、Name、Age、Department、Salary和HireDate都是属性,分别代表销售人员编号、姓名、年龄、部门、薪水和入职时间。每个单元格可以看做是一个关系元组(Tuple)。

2.2 实体–联系(Entity-Relationship)模型

基于关系模型的应用往往受限于表格结构上的限制。为了更好地处理复杂的数据关系,引入了ER模型(Entity-Relationship Model),它是一种建模方法,用于描述实体及其之间的联系。

实体(Entity)是指数据的最小单位,实体具有唯一标识符,如学生、课程、作者等。实体的属性(Attribute)描述实体自身的特征,比如学生的姓名、性别、年龄、住址等。

联系(Relationship)是实体间的关联,联系指定两个实体之间存在某种依赖关系。联系分为三类:

  1. 一对一
  2. 一对多
  3. 多对多

在ER模型中,实体用圆圈表示,用矩形框表示属性;联系用菱形表示,不同类型的联系有不同的颜色。ER模型比表格模型更加直观、易于理解。

例如,对于上面的销售人员信息表,实体有销售人员(Salesman)、部门(Department)、职务(Position)三个实体,他们之间存在联系“属于”(is a)、“属于”的反向(has a)和“工作在”(works in)三个联系。如下图所示:

在关系模型和ER模型中,都有两种抽象级别,第一级是数据库,第二级是应用程序。第三级是业务逻辑层。数据库的第一级抽象包括关系模型和ER模型,这是理论层次的模型。第二级抽象是由业务需求驱动的,它决定了实体、联系和属性。第三级抽象是应用程序开发者使用的。

2.3 属性的选择

关系模型的优点是易于理解和使用,缺点是不适合于海量数据场景。因此,关系模型一般只适用于少量数据,而非海量数据场景。关系模型最大的问题就是扩展性差,无法应对业务增长带来的快速变化。

关系模型通常采用的是规范化范式,即在关系模式中,所有二元组都应该满足第三范式(3NF)。也就是说,关系模式的所有关系必须为左小,右大。左小意味着不能出现“超键”,右大意味着不能有冗余字段。如果关系不是左小的,或者不是右大的,就需要进行改进。

另一方面,ER模型能够很好地适应业务变化,因为它直接表示了实体及其之间的联系,并且不受规范化的限制。但ER模型没有指定主键和外键,所以数据库的实现方式可能不同。

2.4 SQL语言和性能优化

关系数据库管理系统(RDBMS)通常支持SQL语言,该语言被广泛用于关系数据库的访问、管理和操纵。SQL语言的语法简单易懂,编写速度快,并且具备强大的功能,可用于复杂的查询、事务处理、视图和触发器。

虽然SQL语言容易上手,但是要确保它运行得非常快,才能获得良好的用户体验。由于关系模型的设计目标就是高效率,所以优化SQL语句的性能至关重要。

一般来说,优化SQL语句的方法有以下几种:

  1. 使用索引
  2. 优化查询计划
  3. 使用绑定变量
  4. 调整并发控制策略
  5. 数据分布均匀

2.4.1 使用索引

索引(Index)是帮助数据库搜索数据时作用的一种数据结构。索引是根据一个或多个属性排序的数据文件,用于加速数据检索过程。索引不是物理的,而是存在数据库的文件中。数据库系统自动维护索引,当用户查询需要检索的数据时,就可以利用索引快速定位数据。

索引的作用:

  1. 提升检索速度
  2. 提高数据库插入、删除、更新的速度

索引建立的原则:

  1. 唯一索引:唯一索引保证唯一性,防止重复数据的插入。
  2. 普通索引:普通索引可以提升检索效率,减少磁盘 IO 操作。
  3. 复合索引:可以同时创建组合索引。

在实际项目中,建议优先考虑使用单列索引或唯一索引。索引可以有效降低查询的时间,使数据库查询响应速度变快。

2.4.2 优化查询计划

查询计划(Query Plan)是查询执行引擎生成查询执行计划的结果。查询计划对查询的执行有重大影响。

查询计划优化包括:

  1. 查询语句分析
  2. 查询计划生成
  3. 查询计划执行

优化查询计划的关键点:

  1. 查看SQL执行计划
  2. 尽可能避免子查询
  3. 在不同表之间关联时,使用连接方式
  4. 避免嵌套循环,可以使用索引
  5. 不要过度索引

2.4.3 使用绑定变量

绑定变量(Bind Variable)是一种特殊的占位符,可以在程序运行过程中动态赋值。它的主要目的是防止SQL注入攻击。

SQL注入攻击是一种黑客攻击类型,它通过把恶意的SQL指令插入到Web表单提交或输入的地方,窃取或修改数据库中的敏感信息。SQL注入攻击常用攻击手法有:

  1. 参数化查询
  2. ORM框架
  3. XML外部实体注入

参数化查询通过预编译的方式解决了SQL注入攻击。预编译过程将SQL语句转换为一个准备好的格式,然后再发送给数据库服务器执行。这种方式可以有效防止SQL注入攻击。

ORM框架可以自动完成参数化查询。ORM框架封装了SQL调用接口,屏蔽了底层的数据库细节,将SQL调用过程转换为对象的形式。开发者不需要自己手动构造SQL语句。

2.4.4 调整并发控制策略

并发控制策略(Concurrency Control Policy)是数据库系统用来控制并发访问数据库的策略。并发控制策略决定了多个用户对同一份数据进行操作时的行为。

并发控制策略包括:

  1. 封锁协议
  2. 撤销协议
  3. 两阶段提交协议

封锁协议是指当事务T1需要访问资源R的时候,需要先获得R的封锁。其他事务只能排队等待,直到前面的事务释放了R的封锁。封锁协议可以保证事务正确的互斥执行,但降低了并发度。

撤销协议是指当事务T1需要访问资源R的时候,会检查是否有另外的事务T2正在访问这个资源。如果有,T2必须回滚,才能继续访问资源。撤销协议可以保证事务一致性,但可能会造成死锁。

两阶段提交协议是指由两个阶段组成,第一阶段准备,第二阶段提交。事务T1获取所有需要的资源并记录日志,第二阶段提交时,如果没有冲突,所有的资源才会真正被分配。两阶段提交可以保证事务的完整性,但增加了系统开销。

2.4.5 数据分布均匀

数据分布均匀(Data Distribution Evenly)是指数据库表或数据文件存储在多个结点上,这些结点分布在网络空间中,可以提供更高的可用性。

数据分布均匀可以提升数据库性能,比如:

  1. 数据读写负载均衡
  2. 容灾备份
  3. 数据迁移更快
  4. 可扩展性
  5. 更快的查询速度

2.5 范式和反范式

范式(Normalization)是关系数据库设计的主要原则之一,旨在消除数据冗余,提高数据集的 integrity 和 maintainability。

范式要求关系数据库中不允许存在以下三种数据冗余:

  1. 主属性冗余
  2. 次属性冗余
  3. 关系冗余

范式的特点:

  1. 首先,符合第三范式
  2. 其次,每一个字段都只存储一份数据

范式的优点:

  1. 更容易理解和维护数据
  2. 避免数据重复

范式的缺点:

  1. 插入和更新数据需要更多的时间和计算资源
  2. 删除数据时,需要对整个表进行更新,效率较低

反范式(De-normalization)是范式的一个变种,它强调数据的高度聚合,而不是高度关联。反范式往往导致数据的一致性问题,难以追踪和维护。

2.6 第三范式

第三范式(Third Normal Form,3NF)是关系数据库设计的规范化方法之一。它以“第三范式”为命名,是对第一范式和第二范式的完善。

第三范式包含以下要求:

  1. 每个表只能有一个主键
  2. 不存在任何派生表
  3. 除了主键外,每一个字段都和主键直接相关

第三范式的特点:

  1. 比较稳定,对关系数据结构稳定且不变
  2. 对查询操作的优化较好

2.7 反范式

反范式(De-normalization)是关系数据库设计中,关系模型与实体-关系模型的转换技术。反范式经常带来数据冗余、复杂性、存储开销等问题。

反范式的目的:

  1. 优化数据库查询效率
  2. 简化数据库设计

反范式的做法:

  1. 从高度关联的关系中分离出独立的实体,创建独立的关系
  2. 将那些频繁引用的数据复制到一起

反范式的劣势:

  1. 更新和插入数据效率低下
  2. 需要对数据的一致性进行维护
  3. 破坏了关系模型

3.NoSQL数据库设计

NoSQL(Not Only SQL)是指非关系型数据库的统称。NoSQL通常关注于超大规模数据集的存储和处理。

NoSQL的特点:

  1. 无需固定的表结构
  2. 支持分布式集群
  3. 动态 Schema
  4. 支持 NoSQL 查询语言

3.1 键值对数据库

键值对数据库(Key-Value Store)是NoSQL中最简单的一种存储方式。

键值对数据库通常使用哈希表来存储数据。在这种情况下,数据库不支持复杂的查询,只能按键进行查找。

键值对数据库的优点:

  1. 简单快速
  2. 方便查询
  3. 支持动态 Schema

键值对数据库的缺点:

  1. 无法支持关联查询
  2. 查询性能不稳定

3.2 文档数据库

文档数据库(Document Database)是NoSQL中的一种数据库模型。

文档数据库以 JSON 或 BSON 的格式存储数据,支持丰富的数据类型。它支持查询操作,通过键定位到对应的文档。

文档数据库的优点:

  1. 灵活的数据类型
  2. 支持动态 Schema
  3. 可以支持关联查询

文档数据库的缺点:

  1. 不支持联结查询
  2. 数据查询性能较差

3.3 列数据库

列数据库(Columnar Database)是一种分布式数据存储方案,它将关系数据库中的数据按照列的形式进行存储。

列数据库的优点:

  1. 通过压缩可以有效减少内存使用
  2. 有利于随机访问
  3. 便于对特定列进行查询

列数据库的缺点:

  1. 不支持动态 Schema
  2. 查询性能不稳定
  3. 只支持查询操作

3.4 图形数据库

图形数据库(Graph Database)是一种用于存储和处理复杂数据结构的数据库。

图形数据库通常使用图形结构来存储和处理数据,图中的节点代表实体,边代表关系。图形数据库可以对数据进行复杂的查询,可以发现隐藏的关系。

图形数据库的优点:

  1. 可以处理复杂的数据结构
  2. 支持查询关联关系
  3. 有助于数据分析

图形数据库的缺点:

  1. 无法保证 ACID 特性
  2. 需要额外的存储空间

4.分布式数据库设计

分布式数据库(Distributed Database)是指跨越多台计算机的数据库。

分布式数据库的特点:

  1. 拓扑结构复杂
  2. 部署节点动态变化
  3. 数据复制同步延迟

4.1 CAP原理

CAP原理(CAP Theorem)是分布式数据库领域的理论,它指出一个分布式系统不可能同时满足一致性(Consistency),可用性(Availability)和分区容错性(Partition Tolerance)这三个属性。

在实际应用中,通常会选取其中任意两个属性作为约束条件。

在分布式数据库设计中,一致性是指数据在多个副本之间的一致性,而分区容错性是指分布式环境中节点之间通信不可靠导致的系统停止服务的能力。

对于读取操作,通常可以容忍短暂的不一致性,而对于写入操作,需要保证强一致性。因此,通常选择CA原则作为约束条件。

4.2 BASE原理

BASE原理(Basic Availability Soft State Eventual Consistency,BASIS)也是分布式数据库领域的理论。它是对CAP原理的延伸,它进一步约束分布式数据库的设计。

BASE原理认为,一个分布式系统可以同时满足:

  1. 基本的可用性(Availability):分布式系统在遇到一些硬件故障或者网络异常的情况仍然可以提供正常的服务。
  2. 软状态(Soft State):分布式系统中数据的状态软的持久化,系统中的数据随时可能发生改变。
  3. 最终一致性(Eventual Consistency):分布式系统的数据在一段时间内保持最终一致性,但是通常不会影响客户端的正确性。

BASE原理强调弱一致性模型,通常只选取AP或CP作为约束条件。

4.3 复制策略

复制策略(Replication Strategy)是分布式数据库设计中用于解决一致性问题的一种方法。

复制策略的目标是将数据复制到多个结点,提高数据可用性。通常复制策略分为异步复制和同步复制两种。

异步复制策略:节点之间不实时地进行数据同步,数据不一致,但可以较好的提高吞吐量。

同步复制策略:节点之间实时地进行数据同步,数据完全一致,但可能延迟较大。

4.4 事务处理

事务(Transaction)是指一个操作序列,里面包括对数据库的读、写和更改,这些操作要么全部成功,要么全部失败。事务的目标是保证数据库的原子性、一致性和隔离性。

事务的四大特性:

  1. 原子性(Atomicity):一个事务是一个不可分割的工作单位,事务中诸操作要么全部成功,要么全部失败。
  2. 一致性(Consistency):事务必须是使数据库从一个一致性状态变到另一个一致性状态。
  3. 隔离性(Isolation):一个事务的执行不能被其他事务干扰。
  4. 持久性(Durability):已提交的事务对数据库的更新是永久性的,接下来的其他操作和数据库的故障恢复机制无关。

在分布式数据库中,事务处理通过XA协议实现。

4.5 数据拆分

数据拆分(Data Partitioning)是分布式数据库设计中常用的方法。

数据拆分是指将数据按照一定的规则划分到不同的数据库或服务器上。数据拆分可以有效减少数据集的大小,同时也可以提升查询效率和系统的扩展性。

数据拆分的方法包括垂直拆分、水平拆分和分区。

垂直拆分:将相同表的内容放在一个数据库中,不同表的内容放在不同的数据库中。

水平拆分:将相同表的内容放在一个数据库中,不同表的内容放在不同的数据库中,不同分片中的数据按照一定规则映射到不同的数据库服务器上。

分区:分区(Partition)是指将数据按照一定的规则切分到多个数据库中,比如按时间、按空间、按关键字等。

5.总结

本篇文章的主要内容是数据库设计知识的介绍,涉及了关系模型、ER模型、SQL、性能优化、范式和反范式、NoSQL、复制策略、事务处理、数据拆分五大部分。希望能够帮助大家更好的了解数据库设计的基本原理、知识和技巧,成为后端架构师、高级工程师或DBA的佼佼者。

本文含有隐藏内容,请 开通VIP 后查看