数据库系统的世界观：为何我们需要数据库

第1章　数据库系统的世界观：为何我们需要数据库

我们正身处一个数据爆炸的时代。According to a 2023 IDC report, the global *datasphere*（数据宇宙）is projected to reach 175 zettabytes by 2025 — a number so vast that if every byte were a single grain of sand, we could fill the Pacific Ocean several times over. Twitter users post hundreds of millions of tweets each day; Alibaba handles tens of billions of transactions during a single Double 11 shopping festival; autonomous vehicles generate terabytes of sensor data per hour. Yet beneath this avalanche of digits lies a far more profound question — one that every software engineer, data scientist, and technical decision-maker must confront at some point in their career:

> *既然我们早已拥有文件（File），为何仍然需要数据库？*

A first-time programmer might legitimately wonder: Why can't I just save my user data in a plain `users.txt`, or my financial records in an Excel spreadsheet, or my application logs in a `.csv` file? For toy projects, this works perfectly well. But the moment a system grows beyond a single user, a single machine, or a single point of failure, the cracks begin to show — and they show catastrophically. A user double-clicks "submit" and gets charged twice. A server crashes mid-write and the file becomes corrupted beyond recognition. Two employees edit the same spreadsheet and overwrite each other's work. The seemingly simple act of "saving data" turns out to be one of the most treacherous problems in all of computer science.

本章（This chapter）将正面回答这一核心问题。我们将从数据管理的历史演进出发，剖析文件系统（File System）的三大固有缺陷；然后深入数据库管理系统（Database Management System, DBMS）的内部，逐一展示其五层功能架构如何系统性地解决这些缺陷；接着我们将考察关系模型与 NoSQL 模型的适用边界，理解"没有最好的数据模型，只有最合适的场景"这一重要判断；最后，我们将目光投向分布式时代，勾勒出从单机到集群的宏观驱动力。通过本章，读者将建立起对数据库系统全貌的初步认知，并能用以解释一个朴素但深刻的结论——为什么仅靠文件无法支撑任何严肃的现代应用。

---

1.1　数据管理的演进简史：从结绳记事到文件系统

人类对数据的存储与管理，其历史远比计算机古老得多。早在上古时期，我们的祖先便用结绳记事（Quipu）记录账目，用泥板上的楔形文字记载谷物收成，用甲骨文的卜辞记录王室的重大事件。从信息论（Information Theory）的角度看，这些原始手段的共同本质是：将人类可理解的信息编码（Encode）为某种物理或符号形式，并存放于一个可被再次读取与解读的介质之上。这一基本范式跨越数千年，直到今天依然成立——只不过"介质"从绳结变成了磁盘，从泥板变成了闪存。

计算机时代的数据管理大致经历了三个阶段：

第一阶段：手工管理阶段（1950s 以前）。计算机诞生之初，数据处理完全依赖程序员手动安排。每一个应用程序都需要自行设计数据的物理布局——程序员必须精确知道每一条记录在磁带（magnetic tape）上的字节偏移量，才能正确地读写。这种"数据与程序高度耦合"的模式带来的痛苦是显而易见的：数据结构一旦改变，程序必须重写；同一份数据无法被多个程序共享；任何数据冗余（data redundancy）都意味着双倍的维护成本。

第二阶段：文件系统阶段（1960s—1970s）。随着磁盘（magnetic disk）的普及，操作系统引入了文件系统，将数据组织为层次化的"文件—目录"结构。这是一次巨大的进步：应用程序不再需要关心数据的物理位置，只需通过文件名（filename）和文件路径（file path）这一逻辑抽象，就能访问数据。文件系统提供了诸如打开、关闭、读取、写入、追加等基本操作，并引入了文件锁（file lock）、访问权限（access permission）等机制。这正是今天我们熟知的 `open()`、`read()`、`write()`、`close()` 系统调用（system call）的雏形。

第三阶段：数据库系统阶段（1970s 至今）。1970 年，IBM 研究员 Edgar F. Codd 发表了一篇划时代论文 *"A Relational Model of Data for Large Shared Data Banks"*，提出了关系模型（Relational Model），奠定了现代数据库的理论基础。同年，Codd 的同事 Donald Chamberlin 和 Raymond Boyce 着手实现一种名为 SEQUEL（Structured English Query Language）的查询语言——这便是今天 SQL（Structured Query Language）的直接前身。1979 年，Oracle 发布了第一个商用关系数据库系统，数据库技术从此走入工业界，并在随后半个世纪中深刻重塑了整个软件产业。

那么问题来了：文件系统已经能够"保存数据"，为何还需要数据库？这个问题的答案，并非一句"数据库更强大"能够搪塞。我们必须深入到文件系统的内部，逐一审视其在现代应用场景下的固有缺陷。

---

1.2　文件系统的三大固有缺陷

文件系统（File System）作为操作系统提供的基础设施，毫无疑问是伟大的工程奇迹。Ext4、NTFS、APFS 等现代文件系统在单机环境下提供了近乎完美的数据持久化能力。然而，当应用从"单机单用户"走向"多机多用户"，从"偶尔使用"走向"每秒万次访问"时，文件系统的抽象层级暴露出三个根本性的不足——并发不安全、缺乏语义约束、恢复能力薄弱。下面我们逐一展开分析。

1.2.1 缺陷一：并发不安全（Concurrency Unsafety）

考虑一个最简单的场景：一个电商网站的"商品库存"用一个文本文件 `inventory.txt` 来存储。每次用户下单，系统读取该文件、修改库存数、再写回文件。如果同一时刻有两个用户分别购买同一件商品的两个库存单位，会发生什么？

```python

伪代码：基于文件系统的库存扣减

def purchase(product_id, quantity): with open("inventory.txt", "r") as f: data = f.read() # 步骤 A：读取 stock = int(data) # 步骤 B：解析 stock = stock - quantity # 步骤 C：扣减 with open("inventory.txt", "w") as f: f.write(str(stock)) # 步骤 D：写回 ```

设想如下执行序列：用户甲执行到步骤 B，读出库存为 10；用户乙在同一时刻也执行到步骤 B，同样读出库存为 10；接着甲执行步骤 D，将库存写为 9；乙再执行步骤 D，将库存也写为 9。结果：库存原本应该是 8，实际却变成了 9——一笔商品凭空消失了。这种现象在并发理论（Concurrency Theory）中被称为竞态条件（Race Condition）。

文件系统本身无法解决这个问题。操作系统提供的 `flock()` 或 `fcntl()` 文件锁是"粗粒度"的——它只能保证"同一时刻只有一个进程能打开这个文件"，而无法在文件内部对"某一行、某一字段"加锁。即便我们引入文件锁，多个进程仍然可能交替执行"读—改—写"序列而触发竞态。要彻底解决并发问题，需要的不是文件级锁，而是细粒度的、可序列化的（Serializable）事务机制——而这正是数据库系统的核心能力之一。

更糟糕的是，文件系统的并发问题不止于此。即便我们使用一种"看似聪明的"方案——让每个进程将修改写入一个独立的临时文件，再由一个协调者合并所有修改——也会面临冲突检测（Conflict Detection）、原子提交（Atomic Commit）、失败回滚（Rollback） 等一系列棘手问题。任何在生产环境中尝试过"用文件实现并发控制"的工程师，都会告诉你这条路是何其痛苦。

1.2.2 缺陷二：缺乏语义约束（Lack of Semantic Constraints）

文件系统把数据视为无差别的字节序列（opaque byte stream）——它认识不到一个 `inventory.txt` 中的"10"代表库存数量，更认识不到这个"10"绝不应该是一个负数，也绝不应该超过商品的上架总量。文件系统不知道数据的"含义"，因此无法检查数据是否符合业务规则。

举几个真实可能发生的"灾难"：

• **类型错误**：用户年龄字段被写入 `"twenty"`（字符串而非数字），文件系统毫无察觉，直到后续程序读取时崩溃。
• **范围越界**：商品价格被写入 `-100`（负数），文件系统照单全收。
• **引用悬挂**：订单文件中记录了"用户 ID 10086"，但 `users.txt` 中根本没有这个用户——文件系统无法识别这种"孤立引用"。
• **重复记录**：同一员工被录入了两次，文件系统没有任何机制阻止。

要解决这些问题，应用层必须自行编写大量校验代码——而且这些代码往往分散在系统的各个角落，难以统一维护。数据库系统则将这类校验纳入"数据完整性约束（Integrity Constraints）"机制，通过主键（Primary Key）、外键（Foreign Key）、唯一性（UNIQUE）、非空（NOT NULL）、检查约束（CHECK）、触发器（Trigger）等手段，由数据库自身强制保证数据语义的一致性。即便应用代码存在 bug，数据库也会拒绝非法数据的写入，从而成为系统的一道安全屏障。

更进一步，关系数据库还引入了参照完整性（Referential Integrity） 和域完整性（Domain Integrity） 的概念。前者保证外键引用的目标一定存在，后者保证字段值落在一个合法的"域"内。这些机制并非可有可无——它们将数据一致性从应用层转移到了数据层，使得多个应用共享同一份数据时，无需重复实现校验逻辑。

1.2.3 缺陷三：恢复能力薄弱（Weak Crash Recovery）

文件系统在崩溃恢复方面的能力，仅限于"尽量不丢数据"——例如通过日志（journal）和写时复制（Copy-on-Write, COW）等机制保证文件系统自身元数据的一致性。但是，当一个应用正在"读—改—写"的过程中突然断电，文件系统无法保证应用语义层面的原子性。

回到上面的库存扣减例子。假设系统执行到步骤 D（写回库存）时，服务器突然宕机（crash）。文件系统的日志机制或许能保证"inventory.txt 不会损坏"，但它无法区分以下两种情况：

• 情况 A：步骤 D 已完成，库存确实被扣减；
• 情况 B：步骤 D 未完成，磁盘上的内容可能是"半截旧数据"或"半截新数据"。

如果是情况 B，系统重启后将读到错误的库存——可能少扣了（财务损失），也可能多扣了（用户投诉）。要在应用崩溃、系统宕机、磁盘损坏等任何意外情况下都保持数据的正确性，必须引入数据库特有的恢复机制——写前日志（Write-Ahead Logging, WAL）、检查点（Checkpoint）、影子分页（Shadow Paging）等。这些机制确保了"事务要么全部完成，要么全部回滚"的原子性（Atomicity） 与持久性（Durability）——这正是著名的 ACID 特性 中的两个维度。

事实上，ACID 中的四个字母——Atomicity（原子性）、Consistency（一致性）、Isolation（隔离性）、Durability（持久性）——每一个都是数据库系统需要付出的巨大工程代价。文件系统在设计之初便没有将这些纳入目标，因此它在面对生产级数据管理时，显得力不从心。

1.2.4　三大缺陷的总结

为了便于读者形成整体认知，我们将上述三大缺陷及其对应的数据库解决方案整理如下表：

| 文件系统的缺陷 | 具体表现 | 数据库的解决方案 | |---|---|---| | 并发不安全 | 多个进程同时改写文件会导致竞态条件与数据丢失 | 事务（Transaction）与并发控制（Concurrency Control），如两阶段锁（2PL）、多版本并发控制（MVCC） | | 缺乏语义约束 | 应用层必须自行校验数据合法性，易遗漏、易不一致 | 完整性约束：主键、外键、唯一性、非空、检查约束 | | 恢复能力薄弱 | 崩溃后数据可能处于半新半旧的损坏状态 | 写前日志（WAL）、检查点、ARIES 等恢复算法 |

这三大缺陷并非文件系统设计的"失误"，而是其抽象层级所决定的根本局限——文件系统的职责是管理字节，而非理解数据。一旦应用需要对数据进行"理解、校验、协调、保护"，便自然而然地需要一层更高级的抽象。这层抽象，就是数据库管理系统。

---

1.3　数据库管理系统的五层架构：一个图书馆的比喻

如果说文件系统是一堆杂乱无章的纸箱，那么数据库管理系统则是一座配有专业管理员的现代化图书馆。为了帮助读者建立直觉，我们先用一个比喻——图书馆与索引卡片——来描绘数据库的内部运作。

想象一座大型图书馆：书架上整齐地码放着百万册图书，每本书都有唯一的索书号（call number），便于定位；图书管理员负责新书上架、旧书下架、借出登记、归还入库；当读者需要查找某本书时，他不会从第一个书架开始逐本翻找，而是先查阅目录卡片（catalog card）——目录上写着"该书位于第 X 排第 Y 列"，读者据此直奔目标位置；每天闭馆后，管理员还要进行一次盘点（inventory），确保账目与实物一致；万一遇到火灾或水灾，图书馆还有异地备份（offsite backup）可供恢复。

这正是数据库管理系统的真实工作方式。书架对应磁盘，索引卡片对应索引，管理员对应 DBMS 内部各个功能模块。一个完整的 DBMS 通常可以划分为五个核心层次，每个层次各司其职，又彼此协作：

```mermaid flowchart TB subgraph UI["用户接口层 User Interface"] SQL["SQL / API 调用"] end

subgraph QP["查询处理器 Query Processor"] PARSER["解析器 Parser"] OPTIMIZER["优化器 Optimizer"] EXECUTOR["执行器 Executor"] end

subgraph TM["事务管理器 Transaction Manager"] CONC["并发控制 Concurrency Control"] LOG["日志管理 Log Manager"] end

subgraph BM["缓冲区管理器 Buffer Manager"] CACHE["缓存池 Buffer Pool"] REPLACEMENT["置换算法 LRU / Clock"] end

subgraph SE["存储引擎 Storage Engine"] INDEX["索引管理 Index Manager"] DISK["磁盘管理 Disk Manager"] FILE["文件管理 File Manager"] end

SQL --> PARSER PARSER --> OPTIMIZER OPTIMIZER --> EXECUTOR EXECUTOR --> CONC EXECUTOR --> CACHE CONC --> LOG CACHE --> INDEX INDEX --> DISK DISK --> FILE LOG --> DISK ```

1.3.1　第一层：存储引擎（Storage Engine）

存储引擎是数据库系统最底层的"仓库管理员"，负责将数据以特定的格式组织并持久化到磁盘之上。具体而言，它管理着三类对象：

• **数据文件（Data Files）**：实际存放表数据的物理文件，通常以页（page）或块（block）为基本单位（常见大小为 4KB、8KB 或