数据库系统演进与架构总览 / Database System Evolution and Architectural Overview

数据库系统是现代信息系统的基石，从银行交易到社交网络，其身影无处不在。然而，这一看似简单的“数据容器”背后，隐藏着长达半个世纪的技术演进与架构博弈，以及支撑其高可用、高可靠、高性能的核心设计哲学。本书将带领读者穿透抽象的数据模型与SQL接口，深入存储引擎的字节级组织、查询优化器的代价模型权衡、分布式事务的共识协议抉择，以及故障恢复的写 ahead log 机制，全景式剖析数据库系统的核心内幕。本章作为全书开篇，旨在建立认知框架：我们将追溯数据库从层次/网状模型到关系型革命，再到NoSQL运动与NewSQL复兴的技术演进脉络；明确定义存储引擎（Storage Engine）、查询处理器（Query Processor）、事务管理器（Transaction Manager）与恢复管理器（Recovery Manager）四大核心组件的职责与交互；对比共享磁盘（Shared-Disk）、共享内存（Shared-Memory）与无共享（Shared-Nothing）三类物理架构的优劣与适用场景；并直面数据爆炸、实时分析、云原生等当代挑战，从而奠定本书“深度原理、实践导向”的技术基调。

1.1 演进历程：从层次模型到NewSQL的范式转移

数据库系统的演进并非线性技术迭代，而是由数据规模、访问模式、硬件环境三大驱动力催生的范式转移。每一次转移都伴随着对前一时代核心假设的质疑与重构。

1.1.1 前关系时代：层次与网状模型的商业实践（1960s-1970s）

在关系模型诞生前，层次模型（Hierarchical Model） 与网状模型（Network Model） 主导了商业数据管理。它们的共同特点是物理结构暴露于逻辑视图，应用程序需显式处理记录间的导航路径。

层次模型以树形结构组织数据，父子关系为1:N。其典范是IBM的IMS（Information Management System），1968年问世，至今仍运行于全球金融、保险核心系统。IMS的“数据库描述（DBD）”与“程序通信块（PCB）”定义了物理存储结构，应用程序通过`GU`（Get Unique）、`GN`（Get Next）等原语在树中遍历。这种设计的优势在于导航路径固定，预取效率高，非常适合当时顺序访问为主、事务边界清晰的批处理场景（如工资单计算）。其致命缺陷在于结构僵化：若需查询“员工的供应商信息”这种跨分支路径，必须编写复杂导航逻辑，或重构整个数据库结构。

网状模型通过“记录类型”与“集合”实现更灵活的图结构，允许M:N关系。1971年CODASYL（Conference on Data Systems Languages）发布的DBTG报告成为其标准。典型系统如IDMS、ADABAS。其数据操纵语言（DML）同样基于导航：应用程序维护“当前记录”与“区域”，通过`OBTAIN`、`CONNECT`等命令在记录间跳转。虽然解决了层次模型的连接限制，但应用程序与物理存储紧耦合，数据独立性极差。一次查询往往需要数十行导航代码，且优化完全依赖程序员经验。

这一时期的核心矛盾是：数据复杂性增长（如供应链涉及供应商、零件、订单、 shipment 的多对多关系）与导航式编程的脆弱性之间的冲突。Codd的划时代论文正是针对此痛点而生。

1.1.2 关系革命：数学基础与商业化浪潮（1970s-1980s）

1970年，IBM研究员Edgar F. Codd发表论文《A Relational Model of Data for Large Shared Data Banks》，提出用集合论与谓词逻辑描述数据。其核心洞见是：数据独立于物理存储，所有操作均基于关系（表）的数学变换。用户只需声明“要什么”（What），而非“如何获取”（How）。

关系模型的三大基石： 1. 单一数据结构——关系（Relation）：二维表，每行元组唯一，列有序但列名无序。 2. 完整性约束：实体完整性（主键非空）、参照完整性（外键约束）、用户定义完整性。 3. 关系操作集：以关系代数（选择、投影、连接、并、差）和关系演算（元组/域演算）为理论基础，最终体现为SQL（Structured Query Language）。SQL的声明式特性使数据库管理系统（DBMS）成为查询优化器，可基于数据分布、索引、统计信息选择最优执行计划。

商业化起点：1979年，Oracle（前身Relational Software, Inc.）发布首个商用关系型数据库。随后IBM DB2（1983）、Sybase（1984）、Informix（1986）、Microsoft SQL Server（1989）相继问世。MySQL于1995年诞生，以开源、轻量、插件式架构赢得Web 1.0时代青睐。

关系型数据库的技术胜利在于：

• **数据独立性**：逻辑模式变更（如增加列）不影响物理存储，应用程序只需调整视图。
• **查询优化**：连接顺序、索引选择、物化视图等优化技术使复杂查询效率可预测。
• **ACID事务**：通过锁、多版本并发控制（MVCC）、预写日志（WAL）保障一致性，简化应用开发。
• **标准接口**：ODBC（1992）、JDBC（1997）实现应用与数据库解耦。

但关系模型也有理论边界：难以高效表达半结构化数据（如JSON文档）、图关系（如社交网络）、时序数据（如传感器流）。这为后续NoSQL崛起埋下伏笔。

1.1.3 NoSQL运动：分布式与灵活性的权衡（2000s-2010s）

21世纪初，Web 2.0应用（如Google、Facebook、Amazon）面临数据量指数级增长（PB级）、高并发写入（每秒百万级请求）、水平扩展需求。传统关系数据库在扩展性、Schema rigidity、特定数据模型（如键值、文档）上显得笨拙。

2006-2010年，NoSQL（Not Only SQL）思潮兴起，核心主张是为分布式与特定模型牺牲部分ACID或SQL兼容性。主要流派：

1. 键值存储（Key-Value Stores）：最简模型，如Amazon Dynamo（2007论文）、Redis。Dynamo设计为最终一致性、无中心节点、可调节的NWR模型（N副本数、W写成功数、R读成功数）。其一致性哈希环、向量时钟、Merkle树检测冲突等机制成为后续分布式系统标配。实践案例：Amazon购物车数据存储，允许短暂不一致以换取99.99%的可用性。

2. 列族数据库（Column-Family Stores）：Google BigTable（2006论文）开创，数据按列族物理存储，适合稀疏宽表。HBase（Hadoop生态）、Cassandra（Facebook，融合Dynamo与BigTable）为代表。Cassandra采用分区键+聚类键两级结构，写操作仅追加WAL与Memtable，读需合并SSTable，实现高吞吐写入。实践案例：Facebook消息系统，存储用户收件箱，按用户ID分区，每个分区内按时间戳聚类。

3. 文档数据库（Document Databases）：以MongoDB（2009）、CouchDB为代表，存储类JSON文档，支持嵌套结构与局部索引。优势：Schema灵活，开发迭代快；劣势：缺乏跨文档事务（早期版本）、连接需应用层处理。实践案例：内容管理系统（CMS）存储文章、评论、用户配置，每篇文章为独立文档，可独立扩展。

4. 图数据库（Graph Databases）：专为关系遍历优化，如Neo4j（属性图模型）、TigerGraph。存储节点与边，使用Cypher查询语言。实践案例：社交网络“朋友的朋友”查询，或欺诈检测中的资金流转路径分析，在Neo4j中为O(1)复杂度，而在关系数据库中需多层JOIN。

NoSQL的核心取舍：遵循CAP定理（一致性、可用性、分区容错性三者不可兼得），在分布式场景下通常选择AP（可用性+分区容错性），如Dynamo/Cassandra；或CP（一致性+分区容错性），如HBase（依赖ZooKeeper选主）。这导致强一致性场景（如银行转账）需应用层补偿，增加复杂度。

1.1.4 NewSQL复兴：分布式与ACID的再融合（2010s-至今）

NoSQL的“牺牲一致性”引发了对强一致性分布式事务的回归需求，尤其是金融、电商等场景。同时，硬件进步（SSD普及、RDMA网络）与分布式共识算法（Paxos、Raft）成熟，催生了NewSQL：兼具SQL支持、分布式扩展、ACID事务。

里程碑系统：

• **Google Spanner**（2012论文）：全球分布式数据库，通过**TrueTime API**（原子钟+GPS实现全球时钟同步）与**Paxos组**复制，提供外部一致性（External Consistency）与跨地域强一致性。其**2PC优化**（协调者故障恢复）、**多版本时间戳**机制是工程奇迹。
• **CockroachDB**：开源Spanner实现，基于Raft共识，使用**HLC（混合逻辑时钟）** 近似TrueTime，实现跨地域事务。
• **TiDB**：国内PingCAP开源，兼容MySQL协议，存储层为**TiKV**（基于Raft的分布式KV），计算层为**TiDB Server**（SQL解析、优化、执行）。其**两阶段提交（2PC）** 与**PD（Placement Driver）** 调度器实现弹性扩缩容。
• **YugabyteDB**：兼容PostgreSQL/Cassandra API，底层为**DocDB**（分布式文档存储），使用Raft复制。

NewSQL的技术共性： 1. 无共享架构（Shared-Nothing）：数据分片（Sharding）后，每片独立计算存储，避免单点瓶颈。 2. 共识协议：每个分片副本组（Replica Group）内使用Raft/Paxos保证副本一致性。 3. 分布式事务：通常采用优化2PC，如Spanner的Paxos-based 2PC，将协调者角色与Paxos Leader绑定，减少故障恢复复杂度。 4. 全局时钟：Spanner的TrueTime或HLC，为分布式事务提供全局单调递增时间戳，解决跨节点事务顺序问题。

实践案例：某跨境电商平台，订单库使用TiDB分片存储，用户地域不同但需实时查看订单状态。TiDB的全局时间戳确保“下单”与“支付”事务即使跨地域也严格有序，而Cassandra可能因时钟漂移导致支付早于下单的逻辑错误。

1.1.5 演进规律总结

| 时代 | 代表模型/系统 | 驱动因素 | 核心优势 | 关键妥协 | |------|--------------|----------|----------|----------| | 1960s | IMS（层次） | 商业数据自动化 | 导航高效，批处理友好 | 数据独立性差，查询僵化 | | 1970s | CODASYL（网状） | 复杂关系建模 | 支持M:N，灵活图结构 | 应用耦合物理，开发困难 | | 1980s | Oracle/DB2（关系） | 数据独立性需求 | 声明式查询，ACID，标准SQL | 扩展性受限，Schema刚性 | | 2000s | Dynamo/Cassandra（NoSQL） | Web规模数据与并发 | 水平扩展，高可用，灵活模型 | 弱一致性，有限查询 | | 2010s | Spanner/TiDB（NewSQL） | 分布式强一致性需求 | 全球部署，SQL+扩展+ACID | 延迟敏感，运维复杂 |

演进本质是在一致性、可用性、扩展性、性能、开发效率之间寻找新的平衡点。关系型数据库在OLTP场景仍占主导（据DB-Engines 2023统计，前10名中7个为关系型），但NoSQL/NewSQL在特定场景（时序、图、全球分布）已不可或缺。

1.2 核心组件定义：数据库的“四大支柱”

无论架构如何演变，现代数据库系统均可分解为四个逻辑组件，它们协同工作，向上提供数据管理服务。

1.2.1 存储引擎（Storage Engine）：数据的物理管家

存储引擎负责数据在持久化介质（磁盘/SSD）上的组织、读写、缓存，是数据库I/O性能的基石。

关键子模块：

• **缓冲池（Buffer Pool）**：内存中缓存数据页（通常4KB/16KB），减少磁盘访问。采用**LRU/2Q/ARC**等算法管理。**写策略**：**Write-Through**（同时写缓冲池与磁盘，安全但慢） vs **Write-Back**（仅写缓冲池，后台刷盘，快但丢数据风险）。主流数据库（InnoDB、SQL Server）默认Write-Back，依赖WAL保证持久性。
• **数据组织**：
• **堆文件（Heap File）**：无序记录存储，插入快，查询需全表扫描。适合临时表。
• **索引组织表（IOT）**：数据按主键顺序存储（如InnoDB的聚簇索引），范围查询快，但插入可能页分裂。
• **日志结构合并树（LSM-Tree）**：写先追加到内存结构（Memtable），满后刷为磁盘**SSTable**（Sorted String Table），后台合并。**优势**：写吞吐极高（顺序写），**劣势**：读需合并多个SSTable，空间放大。**代表**：Cassandra、RocksDB（LevelDB优化版）、ScyllaDB。
• **索引结构**：
• **B+树**：平衡多路搜索树，非叶节点仅存键与指针，叶节点链表连接。**适合点查询与范围查询**，但写可能导致分裂。InnoDB、Oracle默认。
• **哈希索引**：等值查询O(1)，但不支持范围。**自适应哈希索引**（InnoDB）监控查询模式，为热点页自动建哈希表。
• **位图索引**：低基数列（如性别），用位图表示，适合OLAP多维查询。
• **WAL（Write-Ahead Logging）**：**所有数据修改先写WAL日志，再写数据文件**。日志仅追加，顺序写快。崩溃恢复时重放（Redo）或回滚（Undo）WAL。**核心原则**：WAL确保“已提交事务不丢失，未提交事务可回滚”。

实践案例：InnoDB的双写缓冲（Doublewrite Buffer）。为防止部分写（Page部分写入导致数据损坏），在刷脏页前先将其复制到共享表空间连续区域（双写缓冲），成功后再写数据页。恢复时，若数据页校验失败，则从双写缓冲恢复。这是牺牲少量性能换取数据完整性的典型设计。

1.2.2 查询处理器（Query Processor）：SQL的翻译官与优化师

查询处理器将SQL语句转化为高效执行计划，包括解析、优化、执行三阶段。

1. 解析器（Parser）：词法/语法分析，生成抽象语法树（AST）。检查语法、语义（如表名/列名存在性、类型兼容性）。输出逻辑查询计划（关系代数表达式）。 2. 优化器（Optimizer）：核心是基于代价的优化（CBO）。为逻辑计划生成多个物理计划（如选择索引、连接顺序、连接算法），估算各计划代价（I/O、CPU、网络），选择最小者。

• **代价模型**：需维护**统计信息**（表的行数、列 Distinct值、直方图、空值率）。`ANALYZE TABLE`定期更新。
• **关键决策**：
• **索引选择**：等值查询选哈希/B+树索引，范围查询选B+树。
• **连接顺序**：小表驱动大表（Nested Loop Join），或使用**哈希连接（Hash Join）**（大表等值连接，内存哈希表），或**排序合并连接（Sort-Merge Join）**（有序输入）。
• **物化**：是否物化中间结果（如子查询结果缓存）。
• **局限性**：统计信息滞后可能导致次优计划。现代优化器（如Oracle 12c）引入**自适应执行计划**，运行时根据实际行数调整。

3. 执行器（Executor）：按物理计划逐算子执行。主流为火山模型（Volcano Iterator）：每个算子实现`open()`、`next()`、`close()`，拉取式执行。优势：内存友好，支持流水线；劣势：函数调用开销大。向量化执行（如MonetDB、ClickHouse）一次处理一批行（向量），利用SIMD指令，减少调用次数，提升CPU利用率。

实践案例：TPC-H查询6（预测性分析）涉及多表连接与分组。优化器可能选择：

• 若`lineitem`的`l_suppkey`有索引，`supplier`小，则先`supplier`驱动`lineitem`（Nested Loop）。
• 若`part`与`lineitem`均大且`l_partkey`等值连接，则哈希连接。
• 若输入有序（如已按`l_shipdate`索引），则排序合并连接。

不同选择代价可能差10倍，凸显优化器重要性。

1.2.3 事务管理器（Transaction Manager）：并发与一致性的仲裁者

事务管理器确保ACID属性在并发环境下的实现。

• **原子性（Atomicity）**：通过**回滚段（Undo Log）** 实现。事务修改前，旧数据写入Undo Log。若事务 abort，用Undo Log 撤销修改。
• **一致性（Consistency）**：应用层保证业务规则（如余额非负），数据库通过约束（主键、外键、检查约束）辅助。
• **隔离性（Isolation）**：通过**并发控制**实现，防止脏读、不可重复读、幻读。
• **锁机制**：**两阶段锁（2PL）**。增长阶段只加锁，收缩阶段只解锁。**行锁**（InnoDB）、**页锁**（SQL Server）、**表锁**（MyISAM）。**死锁检测**（wait-for graph）与**超时**。
• **多版本并发控制（MVCC）**：每个数据行保留多个版本，读操作读取*