数据库概览

一、数据库问题与关系数据库定位

1.1 数据库解决的两个核心问题

数据库系统主要解决两个问题：

1. 数据管理：外部世界有各种各样的信息，这些信息如何在计算机里进行有效的管理
2. 高效访问：用户如何方便、快捷地访问到想要的数据

所以数据库既有管理数据的问题，也有一个效率的问题。

二、数据库发展简史

2.1 发展历程

2.2 为什么网状数据库没有普及

网状数据库用图结构来表达数据之间的联系——定义好节点和边，就可以把任意两个对象关联在一起。但它最大的问题是查询语言比较复杂：用户必须告诉数据库数据在哪里、怎么访问到它。这使得它的应用场景一直局限在 IBM 大型机这样的专业环境中，难以铺开。

在计算机里面，面向用户的设计不是越复杂越好，而是越简单越好——越简单，越可以有更多的用户去用你的系统。

2.3 关系数据库为什么经久不衰

1. 简单的数据模型：一切都是一张表（表格），理解起来非常方便
2. 方便的查询语言（SQL）：从一开始就遵循用尽可能接近自然语言的方式去定义查询语言，用户像写一段自然语言一样描述想要的数据
3. 完善的事务机制：确保数据不丢失

关系数据库花了十年的时间，干的事情就是从 SQL 语言到形成一段程序，这段程序能从硬盘里把要找的数据找出来。这个转换过程（查询处理和优化）是整个关系数据库研究的核心。

三、数据与信息

3.1 数据与信息的区分

在数据库语境中有一个重要约定：

• 信息（Information）：存在于现实世界中的各种内容（比如教室在哪里、课程名称、教师是谁、学生有哪些）
• 数据（Data）：当信息被放入计算机、变成 0/1 符号之后，就称为数据

3.2 数据管理的内容

数据管理是数据库的核心职责，包括：

• 数据的收集
• 数据的整理和组织（尤其是组织方式——数据有很多，但在数据库里怎么组织是核心内容）
• 数据的存储（存在硬盘上，到底怎么存）
• 数据的检索（怎么快速访问）

四、数据库的定义与关键特性

4.1 数据库的核心定义

数据库是长期存储在计算机内、统一管理的、可供各种用户共享的、具有较小冗余度、数据间联系紧密、具有数据独立性的数据集合。

4.2 关键特性详解

（1）长期存储在计算机内

• 数据不是放在内存里的（内存一关机就没了）
• 必须考虑数据在硬盘中的存储
• 数据处理在内存中进行，但存储需要考虑硬盘和内存两种不同介质之间的组合管理

（2）统一管理（数据模型）

• 每种数据库都有一个数据模型（Data Model）
• 关系模型就是一张表，层次/网状也各有模型
• 所有数据都以同一种模型来管理

（3）各种用户共享

• 数据库建好之后一定不是只给一个用户用的
• 大量用户并发访问会带来性能挑战（如 12306 春运、淘宝双十一）

（4）较小冗余度

• 数据在机器里不能存很多份，只能存一份
• 不仅是数据本身的复制问题，还有信息的冗余（在关系模式规范化中会详细讨论）

（5）数据间联系紧密

• 数据库最主要的目的不是为了存数据，而是把数据之间的关系建立起来
• 比如一个学生在不同系统里填了多张表，需要把所有这些信息关联到一起

（6）数据独立性（Data Independence）

• 数据库三层架构使得每一层的变化不会影响其他层
• 详见下文第六节

五、DBMS 的架构位置

数据库管理系统（Database Management System, DBMS）在软件体系中的位置：

1
2
3
4
5
6
7
应用软件
   ↓
数据库管理系统 (DBMS)    ← 核心软件（与操作系统并称）
   ↓
操作系统
   ↓
硬件

数据库和操作系统一直被认为是核心软件。我们国家要实现国产化替代，最主要的替代对象一个是操作系统，一个就是数据库。最多再往上一层是中间件。

数据库的内部实现和操作系统有非常紧密的关系，计算机系统技术的提升（如 RDMA、新存储介质）会对数据库带来很大的影响。

六、数据库的三层架构与数据独立性

6.1 三层架构

三层架构的来源：数据库建好之后是共享的，不同用户都会来用，但每个用户有自己的需要（比如本科教学系统只关心本科教学数据，研究生管理系统只关心研究生数据）。所以需要为每个用户定义其相应的数据访问内容。

6.2 数据独立性

数据库把数据组织分成三层之后，每层之间通过映射关系来连接。当某一层发生变化时，只要修改相应的映射关系，对上层用户来说就是透明的。

这是一个非常重要的概念。你那边数据库改了（比如因为数据规模变大，分库分表了），如果这个操作会影响到外面的应用程序，那程序员还得被叫回来重新改程序——这是非常糟糕的事情。所以数据库通过构建这样一套管理体系，让用户在使用的时感受到极大的方便。

三层架构的构成是三个模式 + 两层映射。

七、OLTP、OLAP 与 HTAP

7.1 OLTP（Online Transaction Processing，在线事务处理）

• 偏向管理操作：存钱、取钱、查询余额等
• 对单条或少量数据的读写操作
• 关系数据库最传统、最主要的应用模式
• 需要完善的事务支持，确保数据不丢失

7.2 OLAP（Online Analytical Processing，在线分析处理）

• 偏向分析操作：用户画像、趋势分析等
• 对大量数据做综合性的统计分析和判断
• 数据来源是各个不同的数据库/系统（排课系统、教学系统等）
• 将数据集成到数据仓库（Data Warehouse）中，再进行分析

OLAP 有两个关键点——（1）在线：系统必须快速响应，不能当天提出查询却要次日才返回结果；（2）分析：不是对一条数据，而是对很多条数据做复杂操作，而且要能快速响应。

7.3 HTAP（Hybrid Transactional/Analytical Processing）

• 将 OLTP 和 OLAP 两种能力结合在同一个系统中
• 在此之前，数据库产品通常有 TP 版本和 AP 版本分开（如华为 GaussDB 有 GaussDB T 和 GaussDB A）
• 分布式数据库出现后，两者的结合成为可能
• 这是当前数据库系统发展的重要趋势之一

八、分布式数据库与云原生架构

8.1 分布式数据库的发展动机

早期：解决网络通信问题。在早期计算机网络不发达的时候，银行每个网点有各自的数据库，数据放在各地，互相之间很少通信，通过中央数据库来协调。

后来：解决性能问题。一台机器处理不了那么多数据，就把数据分布到多台机器上同时处理——相当于用多台机器的计算能力来加速。

这就好像 CPU 和 GPU 的对比——CPU 是所有的处理都在一个或少几个核里进行；GPU 有成千上万的计算单元可以同时处理数据。分布式数据库也是类似的思路。

8.2 分布式数据库的优势

• 高性能：多节点同时处理
• 高可用：数据有副本，一两台机器宕机不影响使用
• 高可扩展（横向扩展）：存储空间不够了就加两台机器，水平扩展能力强

在 Hadoop/Spark 等分布式平台上，所有数据都带有副本——因为数据分布在不同的机器上，一台机器坏了那一部分数据就没了，所以必须冗余存储。

8.3 云原生数据库

云计算出现后，分布式数据库有了新的形态：

• Share Everything 架构（如阿里 OceanBase、PoloDB）：每台机器有计算模块和存储模块，数据分布在不同机器上，共同完成查询请求
• 存算分离（Storage-Compute Separation）：充分利用独立的存储系统和计算资源，存储形成”存储云”，计算节点可以弹性伸缩
• 分布式缓存层：通过分布式内存管理，把多台机器的内存放在一起，形成大容量的缓存层，减少对硬盘的访问

8.4 分布式事务的挑战

分布式数据库在 OLTP 场景下的难点在于分布式事务：

• 当一个事务涉及多个节点时，效率会比较低
• 早期做法是”一写多读“（一个节点负责写，其他节点可以读），以此避免分布式事务的问题
• 现在像华为、阿里的产品已经可以实现多写多读，即完全的分布式事务

8.5 国产数据库发展

• 近十年国产数据库技术进步非常快
• 大型互联网应用所用的数据库已基本是国产
• 银行领域正在全面推进国产化替代，预计到今年年底或明年年底，国内主要银行会完全换成国产数据库
• 银行是数据库的标志性行业——如果银行应用都能用国产数据库支撑，说明国产数据库的能力有了很好的保证

九、大数据时代

9.1 大数据的本质

大数据最重要的是覆盖面，而不仅仅是数据规模。

当真正分析一件事时，可以获得关于这件事方方面面的数据。不像以前做数据挖掘时，只有单一的数据来源（如超市数据就只有超市数据）。这才是大数据和以前数据最大的差别。

9.2 大数据带来的思维变化

大数据之前：非常关心用统一的模型去描述所有数据（关系模型描述所有数据，网状模型描述所有数据）。

大数据之后：数据类型极大扩展，且大数据更偏分析型而不是事务型，不需要对事务做太多支撑。因此产生了各种不同类型的数据库：

• 键值对数据库：与分布式平台相关，用 key-value 方式管理
• 文档数据库：直接存一个很大的文档
• 图数据库（Graph Database）：在大数据时代非常重要，可以把各种不同来源的数据直接放在图里，通过加边的方式建立关联
• 时序数据库（Time-Series Database）
• 向量数据库（Vector Database）

9.3 NoSQL

NoSQL = Not Only SQL：不只是 SQL 语句，还可以做很多其他事情。到了分布式之后，继承了云的高可用能力。

9.4 国产数据库产品格局

基本上每家国产数据库厂商现在都有四到五个数据库产品：

• 关系数据库（TP）
• 分析数据库（AP）——TP 和 AP 有时合并
• 图数据库
• 时序数据库
• 近两年再加一个向量数据库

9.5 数据驱动 vs 模型驱动

大数据出来之后，有一个重要的思维转变。以前我们非常关注模型，要去建一个非常好的模型，从数据上分析出深入的东西——我们说一个人很聪明，总是说他思维能力很强，能举一反三。但大数据出来之后，我们发现光靠数据也可以完成很多复杂的任务。

例子一——IBM Watson：存储了两亿多页资料，问题来了就可以找到相关资料并做出回答。虽然有一定的智能性，但后面的数据起了非常关键的作用。

例子二——机器翻译：早期复旦吴立德教师做机器翻译时，一个重要工作是去建语言模型（还专门招了中文系的教师来建中文语言模型），但中文描述方式太多，模型很难建。有了大数据之后，利用大量中英文语句的匹配对，根据相同含义的不同表达找到映射关系，用简单的关联模型就取得了很好的效果。Google 翻译出来之后，翻译效果一下子提升了很多。

例子三——知识图谱（Knowledge Graph）：计算机本身没有任何知识，但有了大量数据后，可以把人类已经产生的知识用结构化的方式（以图的方式）表达出来——把实体之间的关系用边来表示，把实体自身的信息摘出来。这样就使得计算机或模型在做分析时可以掌握很多知识。知识图谱成为当时非常受关注的方向，很多行业和单位自发建立自己的知识图谱体系。

十、AI 与数据库的融合

10.1 向量数据库与 RAG

大模型产生后，对数据库的一个重要影响就是向量数据库的兴起。

RAG（Retrieval Augmented Generation，检索增强生成） 的原理：

• 大模型可以回答很多问题，但存在幻觉（Hallucination）问题和回答不够针对性的问题
• 如果在大模型回答问题之前，给它提供一部分与问题相关的、真实性较强的专业知识文本
• 大模型结合这些知识和自己的推理能力，可以做出很好的回答
• 向量数据库就是用来做这种知识库构造的
• 由于所有交互的基础是向量，所以与大模型的结合非常容易

10.2 Text-to-SQL / Chat BI

• 用自然语言直接操作数据库：自然语言转成 SQL 语言
• SQL 的语料比较少，所以自然语言转 SQL 在以前很难做到
• 大模型出现后，效果有了很大提高

10.3 AI 辅助数据库运维（AIOps）

• 有了云之后，企业可能有成百上千个数据库（如银行里有几百个大数据库）
• 数据库管理员（DBA）根本忙不过来
• 智能化运维工具开始使用 AI 技术，自动监控和管理数据库

10.4 AI 辅助查询优化

• 数据库的查询处理和查询优化中存在很多不确定性——对代价的估计很难估得准
• 传统方法遇到瓶颈
• 现在开始用 AI 方法来解决这些具有较大不确定性的问题

10.5 大模型理解遗留数据库

很多信息系统建了很多数据库，但开发的人可能早就离开了，过了几年就没人知道这些数据库里到底是什么数据。大模型因为有很好的语言文字理解能力，可以对遗留数据库的内容进行分析和理解。

10.6 AI 与数据库的双向赋能

数据库管理数据的思想也对 AI 有很大的帮助——数据仓库等技术对 AI 的支撑很重要，数据管理的底层思想在 AI 基础平台中也有很大的关联。

十一、数据库安全与加密

11.1 云数据库的安全挑战

有了云数据库之后，数据实际上离开了企业自己的范围（比如在阿里云上租了数据库，数据就到了阿里云的范围内）。企业非常担心数据安全问题——万一云平台被攻破，客户信息就泄露了。

11.2 密态数据库（加密数据库）

做法：数据往数据库里放的时候，先加密再存放。即使数据库被拿走，数据也是加密的，无法直接读取。

带来的问题：加密后数据的顺序可能被打乱——23 岁加密后的结果可能比 22 岁的加密结果更小。原来很多和秩序有关的操作（如比较大小）就无法直接进行了，性能会受到很大影响。

解决方案——同态加密：像华为 GaussDB 用了同态加密技术，可以把加密带来的性能损失降到 10% 以下。

11.3 区块链与数据库

数据库技术也在与区块链技术结合，实现数据的不可篡改等特性。

十二、硬件对数据库的影响

12.1 RDMA（Remote Direct Memory Access）

• 一种网络传输协议
• 使得数据中心内多台机器之间的通信速度变得非常快
• 决定了现代分布式数据库架构的可行性：在此之前分布式数据库因为事务验证和数据传输效率很低，有了 RDMA 之后才真正成为可能

12.2 DPU / FPGA

• 很多研究在探索把数据库上的操作（特别是 OLAP 的大规模数据处理）放到 DPU 或 FPGA 上去做
• DPU 上有大量计算节点，虽然单个节点能力不强，但处理数据库的计算绰绰有余
• 数据分到很多计算节点上去算，效率不错

12.3 Flash 闪存（非易失存储）

• 在 Flash 出现之前，数据库领域提升效率的一个核心方向就是解决硬盘读取速度太慢的问题
• Flash 出现后，大量数据可以直接放在 Flash 里，读取速度提高了很多
• 虽然 Flash 比机械磁盘快，但仍比内存慢

12.4 大内存与内存数据库

• 内存增大和分布式内存管理技术出现后，更多数据可以放在内存里
• 内存数据库：所有数据至少在运算时都放在内存里，不需要访问硬盘
• 如股票交易系统就是一个全内存数据库系统——因为对时效性的要求实在太高

十三、数据模型

13.1 概念设计：实体-关系图（ER 图）

现实世界中的信息如何描述？用实体-关系（Entity-Relationship, ER）图：

• 实体：矩形表示（如教师、学生、教室、课程）
• 联系：菱形表示（如主讲关系、选修关系）
• 属性：椭圆表示

联系的多样性：

• 一对一（1:1）：校长和学校——一个校长只能在一个学校任职
• 一对多（1:N）：院系和教师——一个学院有多个教师
• 多对多（M:N）：项目和教师——一个项目有多个教师，每个教师也有多个项目；学生和课程之间也是多对多
• 三元联系：如航班、飞机、旅客构成三元联系

联系本身也可以有属性（如零件用在项目中的数量）。

13.2 数据模型的三个要素

1. 数据结构：实体之间的关系怎么表达（图还是表？）
2. 操作：在数据库上可以执行哪些操作
3. 完整性约束：数据必须满足的约束条件

13.3 层次模型（Hierarchical Model）

• 用树来表达数据之间的联系
• 局限性：很多联系表达不出来——如学生和课程之间的联系、学生和教师之间的联系，硬要用树来表示就会非常麻烦

13.4 网状模型（Network Model）

• 用图来表达数据之间的联系
• 任何节点之间都可以建立关联
• 但编程比较复杂，虽然一直在 IBM 大型机上使用，应用场景始终没有铺开

13.5 关系模型（Relational Model）

• 一切数据都以表（表格）的形式来表达
• 每一列 = 一个字段（Field），代表一个属性
• 每一行 = 一条记录（Record）
• 有关键码（Key）的概念：可以唯一标识表中的每一条记录，也用于建立不同表之间数据的关联

网状模型通过指针来关联数据，而关系模型通过关键码来实现关联。关系表全是表格，理解起来非常方便，所以关系模型最终成为最成功的数据模型。

13.6 对象模型（Object Model）

• 伴随面向对象编程语言而产生
• 优点：可以有类的概念（把所有学生归为同一个类），还可以有方法（不同格式的图像有不同的解析程序，可以直接建模在对象上）
• 后来对象模型被关系模型吸收，形成对象关系数据库（Object-Relational Database）

13.7 为什么后来不再提”模型”概念

到了 90 年代之后，数据库领域不再像之前那样强调提出新的”模型”，原因有二：

1. 关系模型已经成为主导地位，从模型角度做的基本都基于关系模型
2. 新型数据（时序、图等）很难用统一的模型来描述，不同类型的数据采用不同的管理方式

十四、物理存储与块（Block）概念

14.1 块的概念

在物理存储设计中，有一个概念一定要记住——块（Block，也称页 Page）。

块是内存和外存交换信息的最小单元，通常是 4KB 大小。

14.2 为什么块如此重要

在内存中访问数组时，可以直接读写每个元素。但数据放在硬盘上时（不管是机械硬盘还是 Flash），都遵循块的规定：

• 读数据：你想读一个数值？对不起，你必须一次性把整个 4K 的块读出来
• 改数据：对不起，你要先把整个块读到缓冲区，修改完，再整个写回去

每一次操作都是以 4K 为单位的。

14.3 对数据库设计的启示

这个块的概念直接影响到数据库和大规模数据处理的性能。要尽可能让一次性交换的数据规模更大，这样才合算。如果做随机的读写，是非常不合算的。在云平台上，一次数据交换的规模甚至到 MB 级别。

十五、数据库系统架构与查询处理

15.1 DBMS 的工作模式

• 用户/应用程序把指令发送给 DBMS
• DBMS 负责实际的数据库文件访问
• 多个用户同时访问时，都通过 DBMS 来协调
• 对用户来说简单（通过标准 SQL 语言即可），对数据库来说更安全（所有访问都可控）

15.2 内存-硬盘两层存储架构

• 物理文件层（硬盘）：数据持久化存储，宕机后数据仍在
• 系统缓冲层（内存）：所有数据处理都在内存中进行

数据库的查询操作算法，干的最主要的事情就是在内存和硬盘之间怎么倒腾数据。这是数据库算法的最核心之处。

15.3 存储层的关键组件

（1）数据页面（Data Pages） 关系表中的数据最终存放在数据页面上。

（2）日志（Log / Journal）

• 记录所有对数据库的修改操作
• 原始作用：与数据页面相互印证——如果数据页面丢失了，可以通过日志恢复（因为日志记录了所有操作）
• 分布式数据库中的新作用：实现不同节点之间的数据同步——一个节点的数据修改形成日志后，马上传到其他节点

日志是数据库里一个非常重要的内容。

（3）索引（Index）

• 一种辅助数据结构
• 通过对数据的有效组织，实现非常快速的数据访问
• 比如工商银行的数据全部集中在北京的数据库里，但你在上海插卡取钱，系统马上就知道你的密码和余额——这就是索引的功劳

索引是数据库里面一个非常神奇的技术。

15.4 查询处理与优化

SQL 语言是描述性的语言——用户更多是在描述”我想要什么数据”，而不是在描述”数据怎么获得”。这和网状数据库形成鲜明对比：网状数据库你必须告诉它数据在哪里、怎么访问到它。

查询处理的流程：

1. 查询处理层：将描述性的 SQL 转换为内部的查询执行计划
2. 查询优化层：一个查询可以转换出很多种执行方式，需要从中选出最优的一种
3. 查询执行层：实际执行查询程序，访问物理文件

关系数据库花了十年的时间做这件事——从 SQL 语言到形成一段能从硬盘里找出数据的程序。查询处理和查询优化是关系数据库研究中最重要的内容，至今仍然有很多研究工作在进行。

15.5 数据库系统的其他模块

• 权限管理：哪些用户可以访问哪些数据
• 审计与入侵检测：安全管理相关
• 并发控制：多个用户同时访问数据时的协调

十六、数据库工具与生态

• 导入导出工具：在国产化替代中非常重要——原来的数据都在 Oracle、DB2 等数据库中，需要迁移出来
• 同步工具
• 监控运维工具：监控数据库系统正常运行，确保效率
• 中间件与开发工具

十七、数据库与多种技术的融合

数据库技术是多种不同技术的融合：

• 硬件技术：异构计算（DPU/FPGA）、网络通信（RDMA）
• 编译技术：让查询执行的程序语句效率更高
• 操作系统技术：文件管理、内存管理
• 并发/分布式技术：数据库的并发处理与分布式系统的并发处理相互借鉴
• 编程语言连接
• 并行计算（SMP 等）

• Previous
  体系结构概览
• Next
  公理化数系